[people/ms/u-boot.git] / doc / driver-model / UDM-hwmon.txt

The U-Boot Driver Model Project
===============================
Hwmon device subsystem analysis
===============================

Tomas Hlavacek <tmshlvck@gmail.com>
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
--------------------------------

  1) drivers/hwmon/lm81.c
  -----------------------
  The driver is standard dtt. Simple conversion is possible.


  2) 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.


  3) drivers/hwmon/ds1775.c
  -------------------------
  The driver is standard dtt. Simple conversion is possible.


  4) drivers/hwmon/lm73.c
  -----------------------
  The driver is standard dtt. Simple conversion is possible.


  5) drivers/hwmon/lm63.c
  -----------------------
  The driver is standard dtt. Simple conversion is possible.


  6) drivers/hwmon/adt7460.c
  --------------------------
  The driver is standard dtt. Simple conversion is possible.


  7) drivers/hwmon/lm75.c
  -----------------------
  The driver is standard dtt. Simple conversion is possible.


  8) drivers/hwmon/ds1621.c
  -------------------------
  The driver is standard dtt. Simple conversion is possible.


  9) drivers/hwmon/adm1021.c
  --------------------------
  The driver is standard dtt. Simple conversion is possible.
Commit	Line	Data
5df9b142 TH	1	The U-Boot Driver Model Project
	2	===============================
	3	Hwmon device subsystem analysis
	4	===============================
	5
	6	Tomas Hlavacek <tmshlvck@gmail.com>
	7	2012-03-02
	8
	9	I) Overview
	10	-----------
	11
	12	U-Boot currently implements one API for HW monitoring devices. The
	13	interface 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
	21	The functions are implemented by a proper device driver in drivers/hwmon
	22	directory and the driver to be compiled in is selected in a Makefile.
	23	Drivers are mutually exclusive.
	24
	25	Drivers depends on I2O code and naturally on board specific data. There are
	26	few ad-hoc constants put in dtt.h file and driver headers and code. This
	27	has to be consolidated into board specific data or driver headers if those
	28	constants makes sense globally.
	29
	30
	31	II) 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,
93e14596	39	struct hwmon_device_ops *o);
5df9b142 TH	40
	41	The structure being defined as follows:
	42
	43	struct hwmon_device_ops {
93e14596 WD	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);
5df9b142 TH	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
	71	III) 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.