2013-02-22 00:48:37 +01:00
|
|
|
/*
|
|
|
|
|
* This file is part of the coreboot project.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2012 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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <types.h>
|
|
|
|
|
#include <string.h>
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
#include <stdlib.h>
|
2013-02-22 00:48:37 +01:00
|
|
|
#include <device/device.h>
|
|
|
|
|
#include <device/device.h>
|
|
|
|
|
#include <device/pci_def.h>
|
|
|
|
|
#include <device/pci_ops.h>
|
|
|
|
|
#include <console/console.h>
|
|
|
|
|
#include <delay.h>
|
|
|
|
|
#include <pc80/mc146818rtc.h>
|
|
|
|
|
#include <arch/acpi.h>
|
|
|
|
|
#include <arch/io.h>
|
|
|
|
|
#include <arch/interrupt.h>
|
2013-03-20 22:08:04 +01:00
|
|
|
#include <boot/coreboot_tables.h>
|
2013-02-22 00:48:37 +01:00
|
|
|
#include "onboard.h"
|
|
|
|
|
#include "ec.h"
|
|
|
|
|
#include <southbridge/intel/bd82x6x/pch.h>
|
2014-02-23 00:09:48 +01:00
|
|
|
#include <northbridge/intel/sandybridge/gma.h>
|
2013-02-22 00:48:37 +01:00
|
|
|
#include <smbios.h>
|
|
|
|
|
#include <device/pci.h>
|
|
|
|
|
#include <ec/google/chromeec/ec.h>
|
|
|
|
|
|
|
|
|
|
#include <cpu/x86/tsc.h>
|
|
|
|
|
#include <cpu/x86/cache.h>
|
|
|
|
|
#include <cpu/x86/mtrr.h>
|
|
|
|
|
#include <cpu/x86/msr.h>
|
2013-03-13 22:35:01 +01:00
|
|
|
#include <edid.h>
|
2013-02-22 00:48:37 +01:00
|
|
|
#include "i915io.h"
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
vmsg = 1, vio = 2, vspin = 4,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int verbose = 0;
|
|
|
|
|
|
|
|
|
|
static unsigned int *mmio;
|
|
|
|
|
static unsigned int graphics;
|
|
|
|
|
static unsigned short addrport;
|
|
|
|
|
static unsigned short dataport;
|
|
|
|
|
static unsigned int physbase;
|
2013-03-13 22:35:01 +01:00
|
|
|
static u32 htotal, hblank, hsync, vtotal, vblank, vsync;
|
|
|
|
|
|
|
|
|
|
const u32 link_edid_data[] = {
|
|
|
|
|
0xffffff00, 0x00ffffff, 0x0379e430, 0x00000000,
|
|
|
|
|
0x04011500, 0x96121ba5, 0xa2d54f02, 0x26935259,
|
|
|
|
|
0x00545017, 0x01010000, 0x01010101, 0x01010101,
|
|
|
|
|
0x01010101, 0x6f6d0101, 0xa4a0a000, 0x20306031,
|
|
|
|
|
0xb510003a, 0x19000010, 0x00000000, 0x00000000,
|
|
|
|
|
0x00000000, 0x00000000, 0x00000000, 0x4c00fe00,
|
|
|
|
|
0x69442047, 0x616c7073, 0x20200a79, 0xfe000000,
|
|
|
|
|
0x31504c00, 0x45513932, 0x50532d31, 0x24003141,
|
|
|
|
|
};
|
2013-02-22 00:48:37 +01:00
|
|
|
|
|
|
|
|
#define READ32(addr) io_i915_READ32(addr)
|
|
|
|
|
#define WRITE32(val, addr) io_i915_WRITE32(val, addr)
|
|
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
static char *regname(unsigned long addr)
|
|
|
|
|
{
|
|
|
|
|
static char name[16];
|
2013-11-26 02:41:26 +01:00
|
|
|
snprintf(name, sizeof (name), "0x%lx", addr);
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
return name;
|
|
|
|
|
}
|
|
|
|
|
|
2013-02-27 18:54:47 +01:00
|
|
|
unsigned long io_i915_READ32(unsigned long addr)
|
2013-02-22 00:48:37 +01:00
|
|
|
{
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
unsigned long val;
|
|
|
|
|
outl(addr, addrport);
|
|
|
|
|
val = inl(dataport);
|
|
|
|
|
if (verbose & vio)
|
|
|
|
|
printk(BIOS_SPEW, "%s: Got %08lx\n", regname(addr), val);
|
|
|
|
|
return val;
|
2013-02-22 00:48:37 +01:00
|
|
|
}
|
|
|
|
|
|
2013-02-27 18:54:47 +01:00
|
|
|
void io_i915_WRITE32(unsigned long val, unsigned long addr)
|
2013-02-22 00:48:37 +01:00
|
|
|
{
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
if (verbose & vio)
|
|
|
|
|
printk(BIOS_SPEW, "%s: outl %08lx\n", regname(addr), val);
|
|
|
|
|
outl(addr, addrport);
|
|
|
|
|
outl(val, dataport);
|
2013-02-22 00:48:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2013-03-13 22:35:01 +01:00
|
|
|
2560
|
|
|
|
|
4 words per
|
|
|
|
|
4 *p
|
|
|
|
|
10240
|
|
|
|
|
4k bytes per page
|
|
|
|
|
4096/p
|
|
|
|
|
2.50
|
|
|
|
|
1700 lines
|
|
|
|
|
1700 * p
|
|
|
|
|
4250.00
|
|
|
|
|
PTEs
|
2013-02-22 00:48:37 +01:00
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
setgtt(int start, int end, unsigned long base, int inc)
|
|
|
|
|
{
|
2013-03-13 22:35:01 +01:00
|
|
|
int i;
|
2013-02-22 00:48:37 +01:00
|
|
|
|
2013-03-13 22:35:01 +01:00
|
|
|
for(i = start; i < end; i++){
|
|
|
|
|
u32 word = base + i*inc;
|
|
|
|
|
WRITE32(word|1,(i*4)|1);
|
|
|
|
|
}
|
2013-02-22 00:48:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static unsigned long tickspermicrosecond = 1795;
|
|
|
|
|
static unsigned long long globalstart;
|
|
|
|
|
|
|
|
|
|
static unsigned long
|
|
|
|
|
microseconds(unsigned long long start, unsigned long long end)
|
|
|
|
|
{
|
|
|
|
|
unsigned long ret;
|
|
|
|
|
ret = ((end - start)/tickspermicrosecond);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static unsigned long globalmicroseconds(void)
|
|
|
|
|
{
|
|
|
|
|
return microseconds(globalstart, rdtscll());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern struct iodef iodefs[];
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
extern int niodefs;
|
2013-02-22 00:48:37 +01:00
|
|
|
|
|
|
|
|
static int i915_init_done = 0;
|
|
|
|
|
|
2013-03-05 22:32:24 +01:00
|
|
|
/* fill the palette. This runs when the P opcode is hit. */
|
2013-06-05 17:35:52 +02:00
|
|
|
/* and, yes, it's needed for even 32 bits per pixel */
|
2013-03-05 22:32:24 +01:00
|
|
|
static void palette(void)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
unsigned long color = 0;
|
|
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
for(i = 0; i < 256; i++, color += 0x010101){
|
2016-09-19 17:46:33 +02:00
|
|
|
io_i915_WRITE32(color, _LGC_PALETTE_A + (i << 2));
|
2013-03-05 22:32:24 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
static unsigned long times[4096];
|
2013-02-22 00:48:37 +01:00
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
static int run(int index)
|
2013-02-22 00:48:37 +01:00
|
|
|
{
|
|
|
|
|
int i, prev = 0;
|
|
|
|
|
struct iodef *id, *lastidread = 0;
|
|
|
|
|
unsigned long u, t;
|
2013-03-13 22:35:01 +01:00
|
|
|
if (index >= niodefs)
|
|
|
|
|
return index;
|
2013-02-22 00:48:37 +01:00
|
|
|
/* state machine! */
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
for(i = index, id = &iodefs[i]; id->op; i++, id++){
|
2013-02-22 00:48:37 +01:00
|
|
|
switch(id->op){
|
|
|
|
|
case M:
|
|
|
|
|
if (verbose & vmsg) printk(BIOS_SPEW, "%ld: %s\n",
|
2013-03-13 22:35:01 +01:00
|
|
|
globalmicroseconds(), id->msg);
|
2013-02-22 00:48:37 +01:00
|
|
|
break;
|
2013-03-05 22:32:24 +01:00
|
|
|
case P:
|
|
|
|
|
palette();
|
|
|
|
|
break;
|
2013-02-22 00:48:37 +01:00
|
|
|
case R:
|
|
|
|
|
u = READ32(id->addr);
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
if (verbose & vio)
|
|
|
|
|
printk(BIOS_SPEW, "\texpect %08lx\n", id->data);
|
2013-02-22 00:48:37 +01:00
|
|
|
/* we're looking for something. */
|
|
|
|
|
if (lastidread->addr == id->addr){
|
|
|
|
|
/* they're going to be polling.
|
|
|
|
|
* just do it 1000 times
|
|
|
|
|
*/
|
2013-03-05 22:32:24 +01:00
|
|
|
for (t = 0; t < 1000 && id->data != u; t++){
|
2013-02-22 00:48:37 +01:00
|
|
|
u = READ32(id->addr);
|
|
|
|
|
}
|
|
|
|
|
if (verbose & vspin) printk(BIOS_SPEW,
|
|
|
|
|
"%s: # loops %ld got %08lx want %08lx\n",
|
|
|
|
|
regname(id->addr),
|
|
|
|
|
t, u, id->data);
|
|
|
|
|
}
|
|
|
|
|
lastidread = id;
|
|
|
|
|
break;
|
|
|
|
|
case W:
|
|
|
|
|
WRITE32(id->data, id->addr);
|
|
|
|
|
if (id->addr == PCH_PP_CONTROL){
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
if (verbose & vio)
|
|
|
|
|
printk(BIOS_SPEW, "PCH_PP_CONTROL\n");
|
2013-02-22 00:48:37 +01:00
|
|
|
switch(id->data & 0xf){
|
2013-03-13 22:35:01 +01:00
|
|
|
case 8: break;
|
|
|
|
|
case 7: break;
|
|
|
|
|
default: udelay(100000);
|
|
|
|
|
if (verbose & vio)
|
|
|
|
|
printk(BIOS_SPEW, "U %d\n", 100000);
|
2013-02-22 00:48:37 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case V:
|
|
|
|
|
if (id->count < 8){
|
|
|
|
|
prev = verbose;
|
|
|
|
|
verbose = id->count;
|
|
|
|
|
} else {
|
|
|
|
|
verbose = prev;
|
|
|
|
|
}
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
printk(BIOS_SPEW, "Change verbosity to %d\n", verbose);
|
2013-02-22 00:48:37 +01:00
|
|
|
break;
|
|
|
|
|
case I:
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
printk(BIOS_SPEW, "run: return %d\n", i+1);
|
|
|
|
|
return i+1;
|
2013-02-22 00:48:37 +01:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
printk(BIOS_SPEW, "BAD TABLE, opcode %d @ %d\n", id->op, i);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
if (id->udelay)
|
|
|
|
|
udelay(id->udelay);
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
if (i < ARRAY_SIZE(times))
|
|
|
|
|
times[i] = globalmicroseconds();
|
2013-02-22 00:48:37 +01:00
|
|
|
}
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
printk(BIOS_SPEW, "run: return %d\n", i);
|
|
|
|
|
return i+1;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-30 00:35:39 +02:00
|
|
|
int i915lightup_sandy(const struct i915_gpu_controller_info *info,
|
|
|
|
|
u32 pphysbase, u16 piobase, u32 pmmio, u32 pgfx)
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
{
|
2013-03-13 22:35:01 +01:00
|
|
|
static struct edid edid;
|
2013-06-05 17:35:52 +02:00
|
|
|
int edid_ok;
|
2013-03-13 22:35:01 +01:00
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
int index;
|
|
|
|
|
u32 auxin[16], auxout[16];
|
|
|
|
|
mmio = (void *)pmmio;
|
|
|
|
|
addrport = piobase;
|
|
|
|
|
dataport = addrport + 4;
|
|
|
|
|
physbase = pphysbase;
|
|
|
|
|
graphics = pgfx;
|
2013-03-13 22:35:01 +01:00
|
|
|
printk(BIOS_SPEW, "i915lightup: graphics %p mmio %p"
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
"addrport %04x physbase %08x\n",
|
2013-03-13 22:35:01 +01:00
|
|
|
(void *)graphics, mmio, addrport, physbase);
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
globalstart = rdtscll();
|
|
|
|
|
|
2013-03-13 22:35:01 +01:00
|
|
|
|
2013-06-05 17:35:52 +02:00
|
|
|
edid_ok = decode_edid((unsigned char *)&link_edid_data,
|
|
|
|
|
sizeof(link_edid_data), &edid);
|
|
|
|
|
printk(BIOS_SPEW, "decode edid returns %d\n", edid_ok);
|
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
|
|
|
edid.framebuffer_bits_per_pixel = 32;
|
2013-03-13 22:35:01 +01:00
|
|
|
|
|
|
|
|
htotal = (edid.ha - 1) | ((edid.ha + edid.hbl- 1) << 16);
|
|
|
|
|
printk(BIOS_SPEW, "I915_WRITE(HTOTAL(pipe), %08x)\n", htotal);
|
|
|
|
|
|
|
|
|
|
hblank = (edid.ha - 1) | ((edid.ha + edid.hbl- 1) << 16);
|
|
|
|
|
printk(BIOS_SPEW, "I915_WRITE(HBLANK(pipe),0x%08x)\n", hblank);
|
|
|
|
|
|
|
|
|
|
hsync = (edid.ha + edid.hso - 1) |
|
|
|
|
|
((edid.ha + edid.hso + edid.hspw- 1) << 16);
|
|
|
|
|
printk(BIOS_SPEW, "I915_WRITE(HSYNC(pipe),0x%08x)\n", hsync);
|
|
|
|
|
|
|
|
|
|
vtotal = (edid.va - 1) | ((edid.va + edid.vbl- 1) << 16);
|
|
|
|
|
printk(BIOS_SPEW, "I915_WRITE(VTOTAL(pipe), %08x)\n", vtotal);
|
|
|
|
|
|
|
|
|
|
vblank = (edid.va - 1) | ((edid.va + edid.vbl- 1) << 16);
|
|
|
|
|
printk(BIOS_SPEW, "I915_WRITE(VBLANK(pipe),0x%08x)\n", vblank);
|
|
|
|
|
|
|
|
|
|
vsync = (edid.va + edid.vso - 1) |((edid.va + edid.vso + edid.vspw- 1) << 16);
|
|
|
|
|
printk(BIOS_SPEW, "I915_WRITE(VSYNC(pipe),0x%08x)\n", vsync);
|
|
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
printk(BIOS_SPEW, "Table has %d elements\n", niodefs);
|
2013-03-13 22:35:01 +01:00
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
index = run(0);
|
|
|
|
|
printk(BIOS_SPEW, "Run returns %d\n", index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x1 << 28/*R*/|DP_DPCD_REV << 8|0xe;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 4, auxin, 14);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 0 << 31 /* i2c */|1 << 30|0x0 << 28/*W*/|0x0 << 8|0x0;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 3, auxin, 0);
|
|
|
|
|
index = run(index);
|
|
|
|
|
printk(BIOS_SPEW, "Run returns %d\n", index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 0 << 31 /* i2c */|0 << 30|0x0 << 28/*W*/|0x0 << 8|0x0;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 3, auxin, 0);
|
|
|
|
|
index = run(index);
|
|
|
|
|
printk(BIOS_SPEW, "Run returns %d\n", index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_SET_POWER << 8|0x0;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x01000000;
|
|
|
|
|
/* DP_SET_POWER_D0 | DP_PSR_SINK_INACTIVE */
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 5, auxin, 0);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_LINK_BW_SET << 8|0x8;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x0a840000;
|
|
|
|
|
/*( DP_LINK_BW_2_7 &0xa)|0x0000840a*/
|
|
|
|
|
auxout[2] = 0x00000000;
|
|
|
|
|
auxout[3] = 0x01000000;
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 13, auxin, 0);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_TRAINING_PATTERN_SET << 8|0x0;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x21000000;
|
|
|
|
|
/* DP_TRAINING_PATTERN_1 | DP_LINK_SCRAMBLING_DISABLE |
|
|
|
|
|
* DP_SYMBOL_ERROR_COUNT_BOTH |0x00000021*/
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 5, auxin, 0);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_TRAINING_LANE0_SET << 8|0x3;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x00000000;
|
|
|
|
|
/* DP_TRAIN_VOLTAGE_SWING_400 | DP_TRAIN_PRE_EMPHASIS_0 |0x00000000*/
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 8, auxin, 0);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x1 << 28/*R*/|DP_LANE0_1_STATUS << 8|0x5;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 4, auxin, 5);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_TRAINING_PATTERN_SET << 8|0x0;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x22000000;
|
|
|
|
|
/* DP_TRAINING_PATTERN_2 | DP_LINK_SCRAMBLING_DISABLE |
|
|
|
|
|
* DP_SYMBOL_ERROR_COUNT_BOTH |0x00000022*/
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 5, auxin, 0);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_TRAINING_LANE0_SET << 8|0x3;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x00000000;
|
|
|
|
|
/* DP_TRAIN_VOLTAGE_SWING_400 | DP_TRAIN_PRE_EMPHASIS_0 |0x00000000*/
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 8, auxin, 0);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x1 << 28/*R*/|DP_LANE0_1_STATUS << 8|0x5;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 4, auxin, 5);
|
|
|
|
|
index = run(index);
|
2016-09-19 17:46:33 +02:00
|
|
|
auxout[0] = 1 << 31 /* dp */|0x0 << 28/*W*/|DP_TRAINING_PATTERN_SET << 8|0x0;
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
auxout[1] = 0x00000000;
|
|
|
|
|
/* DP_TRAINING_PATTERN_DISABLE | DP_LINK_QUAL_PATTERN_DISABLE |
|
|
|
|
|
* DP_SYMBOL_ERROR_COUNT_BOTH |0x00000000*/
|
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 5, auxin, 0);
|
|
|
|
|
index = run(index);
|
2013-02-22 00:48:37 +01:00
|
|
|
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
if (index != niodefs)
|
|
|
|
|
printk(BIOS_ERR, "Left over IO work in i915_lightup"
|
2013-03-13 22:35:01 +01:00
|
|
|
" -- this is likely a table error. "
|
|
|
|
|
"Only %d of %d were done.\n", index, niodefs);
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
printk(BIOS_SPEW, "DONE startup\n");
|
|
|
|
|
verbose = 0;
|
|
|
|
|
/* GTT is the Global Translation Table for the graphics pipeline.
|
|
|
|
|
* It is used to translate graphics addresses to physical
|
|
|
|
|
* memory addresses. As in the CPU, GTTs map 4K pages.
|
|
|
|
|
* There are 32 bits per pixel, or 4 bytes,
|
|
|
|
|
* which means 1024 pixels per page.
|
|
|
|
|
* There are 4250 GTTs on Link:
|
|
|
|
|
* 2650 (X) * 1700 (Y) pixels / 1024 pixels per page.
|
|
|
|
|
* The setgtt function adds a further bit of flexibility:
|
|
|
|
|
* it allows you to set a range (the first two parameters) to point
|
|
|
|
|
* to a physical address (third parameter);the physical address is
|
|
|
|
|
* incremented by a count (fourth parameter) for each GTT in the
|
|
|
|
|
* range.
|
|
|
|
|
* Why do it this way? For ultrafast startup,
|
|
|
|
|
* we can point all the GTT entries to point to one page,
|
|
|
|
|
* and set that page to 0s:
|
|
|
|
|
* memset(physbase, 0, 4096);
|
|
|
|
|
* setgtt(0, 4250, physbase, 0);
|
|
|
|
|
* this takes about 2 ms, and is a win because zeroing
|
|
|
|
|
* the page takes a up to 200 ms. We will be exploiting this
|
|
|
|
|
* trick in a later rev of this code.
|
|
|
|
|
* This call sets the GTT to point to a linear range of pages
|
|
|
|
|
* starting at physbase.
|
|
|
|
|
*/
|
|
|
|
|
setgtt(0, FRAME_BUFFER_PAGES, physbase, 4096);
|
2013-02-22 00:48:37 +01:00
|
|
|
printk(BIOS_SPEW, "memset %p to 0 for %d bytes\n",
|
2013-03-13 22:35:01 +01:00
|
|
|
(void *)graphics, FRAME_BUFFER_BYTES);
|
link/graphics: New state machine
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-06 02:07:40 +01:00
|
|
|
memset((void *)graphics, 0, FRAME_BUFFER_BYTES);
|
2013-02-22 00:48:37 +01:00
|
|
|
printk(BIOS_SPEW, "%ld microseconds\n", globalmicroseconds());
|
2013-10-28 23:01:54 +01:00
|
|
|
set_vbe_mode_info_valid(&edid, (uintptr_t)graphics);
|
2013-02-22 00:48:37 +01:00
|
|
|
i915_init_done = 1;
|
2013-11-28 15:44:51 +01:00
|
|
|
return i915_init_done;
|
2013-02-22 00:48:37 +01:00
|
|
|
}
|
