blob: 616f197b11867df8d19c829da8895650cec221a6 (
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
|
#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)
{
}
|
