blob: cc5d529c3b539966e67273d10e971965f976320e [file] [log] [blame]
Tomas Hlavacek1e5e9de2012-08-08 01:42:25 +00001The U-Boot Driver Model Project
2===============================
3Hwmon device subsystem analysis
4===============================
5
6Tomas Hlavacek <tmshlvck@gmail.com>
72012-03-02
8
9I) Overview
10-----------
11
12U-Boot currently implements one API for HW monitoring devices. The
13interface is defined in include/dtt.h and comprises of functions:
14
15 void dtt_init(void);
16 int dtt_init_one(int);
17 int dtt_read(int sensor, int reg);
18 int dtt_write(int sensor, int reg, int val);
19 int dtt_get_temp(int sensor);
20
21The functions are implemented by a proper device driver in drivers/hwmon
22directory and the driver to be compiled in is selected in a Makefile.
23Drivers are mutually exclusive.
24
25Drivers depends on I2O code and naturally on board specific data. There are
26few ad-hoc constants put in dtt.h file and driver headers and code. This
27has to be consolidated into board specific data or driver headers if those
28constants makes sense globally.
29
30
31II) Approach
32------------
33
34 1) New API
35 ----------
36 In the UDM each hwmon driver would register itself by a function
37
38 int hwmon_device_register(struct instance *i,
39 struct hwmon_device_ops *o);
40
41 The structure being defined as follows:
42
43 struct hwmon_device_ops {
44 int (*read)(struct instance *i, int sensor, int reg);
45 int (*write)(struct instance *i, int sensor, int reg,
46 int val);
47 int (*get_temp)(struct instance *i, int sensor);
48 };
49
50
51 2) Conversion thougths
52 ----------------------
53 U-Boot hwmon drivers exports virtually the same functions (with exceptions)
54 and we are considering low number of drivers and code anyway. The interface
55 is already similar and unified by the interface defined in dtt.h.
56 Current initialization functions dtt_init() and dtt_init_one() will be
57 converted into probe() and hwmon_device_register(), so the funcionality will
58 be kept in more proper places. Besides implementing core registration and
59 initialization we need to do code cleanup, especially separate
60 driver-specific and HW specific constants.
61
62 3) Special consideration due to early initialization
63 ----------------------------------------------------
64 The dtt_init() function call is used during early initialization in
65 board/gdsys/405ex/io64.c for starting up fans. The dtt code is perfectly
66 usable in the early stage because it uses only local variables and no heap
67 memory is required at this level. However the underlying code of I2C has to
68 keep the same properties with regard to possibility of running in early
69 initialization stage.
70
71III) Analysis of in-tree drivers
72--------------------------------
73
74 1) drivers/hwmon/lm81.c
75 -----------------------
76 The driver is standard dtt. Simple conversion is possible.
77
78
79 2) drivers/hwmon/ds1722.c
80 -------------------------
81 The driver is not standard dtt, but interface is similar to dtt.
82 The interface has to be changed in order to comply to above mentioned
83 specification.
84
85
86 3) drivers/hwmon/ds1775.c
87 -------------------------
88 The driver is standard dtt. Simple conversion is possible.
89
90
91 4) drivers/hwmon/lm73.c
92 -----------------------
93 The driver is standard dtt. Simple conversion is possible.
94
95
96 5) drivers/hwmon/lm63.c
97 -----------------------
98 The driver is standard dtt. Simple conversion is possible.
99
100
101 6) drivers/hwmon/adt7460.c
102 --------------------------
103 The driver is standard dtt. Simple conversion is possible.
104
105
106 7) drivers/hwmon/lm75.c
107 -----------------------
108 The driver is standard dtt. Simple conversion is possible.
109
110
111 8) drivers/hwmon/ds1621.c
112 -------------------------
113 The driver is standard dtt. Simple conversion is possible.
114
115
116 9) drivers/hwmon/adm1021.c
117 --------------------------
118 The driver is standard dtt. Simple conversion is possible.