- 02 12月, 2014 40 次提交
-
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
V2: fix whitespace errors in memx.fuc Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
No code changes. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Probably missing something here, doesn't make a lot of sense to write or+link data into a register whose offset is calculated by the same or+link info.. This is the all I've witnessed the binary driver and vbios doing so far, so it'll do. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The binary driver has been doing this since GF119, and we've somehow gotten away with it. But, TMDS that hasn't been initialised already by the x86 vbios code is distorted without it on GM204. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Not entirely sure why this got bumped at all yet. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Left-over from before a rework a while back. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Logging at trace level, rather than as en error, as it seems conceivable that failure could be normal under certain circumstances (new bios, older sink that doesn't support a particular DPCD address) Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Starting from GM204, certain registers are no longer accessible by the host (or unsigned PMU firmware). This commit implements devinit on PMU, using a signed microcode image, and devinit data, from the VBIOS. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The field at +0x2 is technically processor specific, though I don't know that it's ever mattered in practice (yet). Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
We're about to need to be able to fetch additional chunks of data beyond the primary bios image, which makes fetching a lot more complicated. This splits out the verious shadowing routines to be nothing more than very dumb "fetch this much data from this offset" routines, and leaves the logic of what and how much to fetch in common code. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-