Displaying 3 results from an estimated 3 matches for "r_0x10f910".
Did you mean:
r_0x10f914
2017 Apr 10
0
[PATCH 03/11] nvkm/gddr5: MR calculation for timing table v1.0
...mgf100.c
@@ -50,11 +50,7 @@ struct gf100_ramfuc {
struct ramfuc_reg r_0x10f290[5];
- struct ramfuc_reg r_0x10f300;
- struct ramfuc_reg r_0x10f338;
- struct ramfuc_reg r_0x10f340;
- struct ramfuc_reg r_0x10f344;
- struct ramfuc_reg r_0x10f348;
+ struct ramfuc_reg r_mr[9];
struct ramfuc_reg r_0x10f910;
struct ramfuc_reg r_0x10f914;
@@ -226,6 +222,19 @@ gf100_ram_calc(struct nvkm_ram *base, u32 freq)
if (ret)
return ret;
+ /* Determine ram-specific MR values */
+ for (i = 0; i < 9; i++)
+ ram->base.mr[i] = ram_rd32(fuc, mr[i]);
+
+ switch (ram->base.type) {
+ case NVKM_RAM_TYPE...
2017 Apr 10
11
Preparations for Fermi DRAM clock changes
No, no, these will not implement Fermi reclocking. This set of patches
contains some of the preparatory work that I deem stable enough to
move upstream. Notable changes
- Training pattern upload routines from GK104+ now shared with GT215+
- Timing calculation for Fermi
- GDDR5 MR calculation from VBIOS timing table v1.0. Also useful for that
pesky GT 240.
- A routine to translate a VBIOS init
2017 Apr 10
14
RESEND Preparations for Fermi DRAM clock changes
Two patches went missing as a result of PEBCAK. No v2 marks as nothing
changed really. Just resending for easier enforcement of patch order
in other people's trees. Sorry for the noise.
Original message:
No, no, these will not implement Fermi reclocking. This set of patches
contains some of the preparatory work that I deem stable enough to
move upstream. Notable changes
- Training pattern