#include "drmP.h" #include "drm.h" #include "nouveau_drv.h" #include "nouveau_drm.h" int nv04_timer_init(struct drm_device *dev) { struct drm_nouveau_private *dev_priv = dev->dev_private; NV_WRITE(NV04_PTIMER_INTR_EN_0, 0x00000000); NV_WRITE(NV04_PTIMER_INTR_0, 0xFFFFFFFF); /* Just use the pre-existing values when possible for now; these regs * are not written in nv (driver writer missed a /4 on the address), and * writing 8 and 3 to the correct regs breaks the timings on the LVDS * hardware sequencing microcode. * A correct solution (involving calculations with the GPU PLL) can * be done when kernel modesetting lands */ if (!NV_READ(NV04_PTIMER_NUMERATOR) || !NV_READ(NV04_PTIMER_DENOMINATOR)) { NV_WRITE(NV04_PTIMER_NUMERATOR, 0x00000008); NV_WRITE(NV04_PTIMER_DENOMINATOR, 0x00000003); } return 0; } uint64_t nv04_timer_read(struct drm_device *dev) { struct drm_nouveau_private *dev_priv = dev->dev_private; uint32_t low; /* From kmmio dumps on nv28 this looks like how the blob does this. * It reads the high dword twice, before and after. * The only explanation seems to be that the 64-bit timer counter * advances between high and low dword reads and may corrupt the * result. Not confirmed. */ uint32_t high2 = NV_READ(NV04_PTIMER_TIME_1); uint32_t high1; do { high1 = high2; low = NV_READ(NV04_PTIMER_TIME_0); high2 = NV_READ(NV04_PTIMER_TIME_1); } while(high1 != high2); return (((uint64_t)high2) << 32) | (uint64_t)low; } void nv04_timer_takedown(struct drm_device *dev) { } c29401'>treecommitdiff
path: root/tests/auth.c
blob: 9b6fca9482e19293ea53ad3f93bacb21f54aff5c (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137