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.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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 "hda_verb.h"
|
|
|
|
#include "onboard.h"
|
|
|
|
#include "ec.h"
|
|
|
|
#include <southbridge/intel/bd82x6x/pch.h>
|
|
|
|
#include <smbios.h>
|
|
|
|
#include <device/pci.h>
|
|
|
|
#include <ec/google/chromeec/ec.h>
|
|
|
|
#include <cbfs_core.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){
|
2013-03-05 22:32:24 +01:00
|
|
|
io_i915_WRITE32(color, _LGC_PALETTE_A + (i<<2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915lightup(unsigned int physbase, unsigned int iobase, unsigned int mmio,
|
2013-03-13 22:35:01 +01:00
|
|
|
unsigned int gfx);
|
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 i915lightup(unsigned int pphysbase, unsigned int piobase,
|
2013-03-13 22:35:01 +01:00
|
|
|
unsigned int pmmio, unsigned int 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);
|
|
|
|
edid.bpp = 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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x1<<28/*R*/|DP_DPCD_REV<<8|0xe;
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 4, auxin, 14);
|
|
|
|
auxout[0] = 0<<31 /* i2c */|1<<30|0x0<<28/*W*/|0x0<<8|0x0;
|
|
|
|
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);
|
|
|
|
auxout[0] = 0<<31 /* i2c */|0<<30|0x0<<28/*W*/|0x0<<8|0x0;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_SET_POWER<<8|0x0;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_LINK_BW_SET<<8|0x8;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_TRAINING_PATTERN_SET<<8|0x0;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_TRAINING_LANE0_SET<<8|0x3;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x1<<28/*R*/|DP_LANE0_1_STATUS<<8|0x5;
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 4, auxin, 5);
|
|
|
|
index = run(index);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_TRAINING_PATTERN_SET<<8|0x0;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_TRAINING_LANE0_SET<<8|0x3;
|
|
|
|
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);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x1<<28/*R*/|DP_LANE0_1_STATUS<<8|0x5;
|
|
|
|
intel_dp_aux_ch(DPA_AUX_CH_CTL, DPA_AUX_CH_DATA1, auxout, 4, auxin, 5);
|
|
|
|
index = run(index);
|
|
|
|
auxout[0] = 1<<31 /* dp */|0x0<<28/*W*/|DP_TRAINING_PATTERN_SET<<8|0x0;
|
|
|
|
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-06-05 17:35:52 +02:00
|
|
|
set_vbe_mode_info_valid(&edid, 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
|
|
|
}
|