forked from yonglongliu/u-boot64
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathUDM-hwmon.txt
118 lines (85 loc) · 3.62 KB
/
UDM-hwmon.txt
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
The U-Boot Driver Model Project
===============================
Hwmon device subsystem analysis
===============================
Tomas Hlavacek <[email protected]>
2012-03-02
I) Overview
-----------
U-Boot currently implements one API for HW monitoring devices. The
interface is defined in include/dtt.h and comprises of functions:
void dtt_init(void);
int dtt_init_one(int);
int dtt_read(int sensor, int reg);
int dtt_write(int sensor, int reg, int val);
int dtt_get_temp(int sensor);
The functions are implemented by a proper device driver in drivers/hwmon
directory and the driver to be compiled in is selected in a Makefile.
Drivers are mutually exclusive.
Drivers depends on I2O code and naturally on board specific data. There are
few ad-hoc constants put in dtt.h file and driver headers and code. This
has to be consolidated into board specific data or driver headers if those
constants makes sense globally.
II) Approach
------------
1) New API
----------
In the UDM each hwmon driver would register itself by a function
int hwmon_device_register(struct instance *i,
struct hwmon_device_ops *o);
The structure being defined as follows:
struct hwmon_device_ops {
int (*read)(struct instance *i, int sensor, int reg);
int (*write)(struct instance *i, int sensor, int reg,
int val);
int (*get_temp)(struct instance *i, int sensor);
};
2) Conversion thougths
----------------------
U-Boot hwmon drivers exports virtually the same functions (with exceptions)
and we are considering low number of drivers and code anyway. The interface
is already similar and unified by the interface defined in dtt.h.
Current initialization functions dtt_init() and dtt_init_one() will be
converted into probe() and hwmon_device_register(), so the funcionality will
be kept in more proper places. Besides implementing core registration and
initialization we need to do code cleanup, especially separate
driver-specific and HW specific constants.
3) Special consideration due to early initialization
----------------------------------------------------
The dtt_init() function call is used during early initialization in
board/gdsys/405ex/io64.c for starting up fans. The dtt code is perfectly
usable in the early stage because it uses only local variables and no heap
memory is required at this level. However the underlying code of I2C has to
keep the same properties with regard to possibility of running in early
initialization stage.
III) Analysis of in-tree drivers
--------------------------------
drivers/hwmon/lm81.c
--------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/ds1722.c
----------------------
The driver is not standard dtt, but interface is similar to dtt.
The interface has to be changed in order to comply to above mentioned
specification.
drivers/hwmon/ds1775.c
----------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/lm73.c
--------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/lm63.c
--------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/adt7460.c
-----------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/lm75.c
--------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/ds1621.c
----------------------
The driver is standard dtt. Simple conversion is possible.
drivers/hwmon/adm1021.c
-----------------------
The driver is standard dtt. Simple conversion is possible.