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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
The U-Boot Driver Model Project
===============================
I/O system analysis
===================
Marek Vasut <marek.vasut@gmail.com>
2012-02-20
I) Overview
-----------
The console input and output is currently done using the STDIO subsystem in
U-Boot. The design of this subsystem is already flexible enough to be easily
converted to new driver model approach. Minor changes will need to be done
though.
Each device that wants to register with STDIO subsystem has to define struct
stdio_dev, defined in include/stdio_dev.h and containing the following fields:
struct stdio_dev {
int flags; /* Device flags: input/output/system */
int ext; /* Supported extensions */
char name[16]; /* Device name */
/* GENERAL functions */
int (*start) (void); /* To start the device */
int (*stop) (void); /* To stop the device */
/* OUTPUT functions */
void (*putc) (const char c); /* To put a char */
void (*puts) (const char *s); /* To put a string (accelerator) */
/* INPUT functions */
int (*tstc) (void); /* To test if a char is ready... */
int (*getc) (void); /* To get that char */
/* Other functions */
void *priv; /* Private extensions */
struct list_head list;
};
Currently used flags are DEV_FLAGS_INPUT, DEV_FLAGS_OUTPUT and DEV_FLAGS_SYSTEM,
extensions being only one, the DEV_EXT_VIDEO.
The private extensions are now used as a per-device carrier of private data and
finally list allows this structure to be a member of linked list of STDIO
devices.
The STDIN, STDOUT and STDERR routing is handled by environment variables
"stdin", "stdout" and "stderr". By configuring the variable to the name of a
driver, functions of such driver are called to execute that particular
operation.
II) Approach
------------
1) Similarity of serial, video and keyboard drivers
---------------------------------------------------
All of these drivers can be unified under the STDIO subsystem if modified
slightly. The serial drivers basically define both input and output functions
and need function to configure baudrate. The keyboard drivers provide only
input. On the other hand, video drivers provide output, but need to be
configured in certain way. This configuration might be dynamic, therefore the
STDIO has to be modified to provide such flexibility.
2) Unification of serial, video and keyboard drivers
----------------------------------------------------
Every STDIO device would register a structure containing operation it supports
with the STDIO core by calling:
int stdio_device_register(struct instance *i, struct stdio_device_ops *o);
The structure being defined as follows:
struct stdio_device_ops {
void (*putc)(struct instance *i, const char c);
void (*puts)(struct instance *i, const char *s); /* OPTIONAL */
int (*tstc)(struct instance *i);
int (*getc)(struct instance *i);
int (*init)(struct instance *i);
int (*exit)(struct instance *i);
int (*conf)(struct instance *i, enum stdio_config c, const void *data);
};
The "putc()" function will emit a character, the "puts()" function will emit a
string. If both of these are set to NULL, the device is considered STDIN only,
aka input only device.
The "getc()" retrieves a character from a STDIN device, while "tstc()" tests
if there is a character in the buffer of STDIN device. In case these two are
set to NULL, this device is STDOUT / STDERR device.
Setting all "putc()", "puts()", "getc()" and "tstc()" calls to NULL isn't an
error condition, though such device does nothing. By instroducing tests for
these functions being NULL, the "flags" and "ext" fields from original struct
stdio_dev can be eliminated.
The "init()" and "exit()" calls are replacement for "start()" and "exit()"
calls in the old approach. The "priv" part of the old struct stdio_dev will be
replaced by common private data in the driver model and the struct list_head
list will be eliminated by introducing common STDIO core, that tracks all the
STDIO devices.
Lastly, the "conf()" call will allow the user to configure various options of
the driver. The enum stdio_config contains all possible configuration options
available to the STDIO devices, const void *data being the argument to be
configured. Currently, the enum stdio_config will contain at least the
following options:
enum stdio_config {
STDIO_CONFIG_SERIAL_BAUDRATE,
};
3) Transformation of stdio routing
----------------------------------
By allowing multiple instances of drivers, the environment variables "stdin",
"stdout" and "stderr" can no longer be set to the name of the driver.
Therefore the STDIO core, tracking all of the STDIO devices in the system will
need to have a small amount of internal data for each device:
struct stdio_device_node {
struct instance *i;
struct stdio_device_ops *ops;
uint8_t id;
uint8_t flags;
struct list_head list;
}
The "id" is the order of the instance of the same driver. The "flags" variable
allows multiple drivers to be used at the same time and even for different
purpose. The following flags will be defined:
STDIO_FLG_STDIN ..... This device will be used as an input device. All input
from all devices with this flag set will be received
and passed to the upper layers.
STDIO_FLG_STDOUT .... This device will be used as an output device. All
output sent to stdout will be routed to all devices
with this flag set.
STDIO_FLG_STDERR .... This device will be used as an standard error output
device. All output sent to stderr will be routed to
all devices with this flag set.
The "list" member of this structure allows to have a linked list of all
registered STDIO devices.
III) Analysis of in-tree drivers
--------------------------------
For in-depth analysis of serial port drivers, refer to [ UDM-serial.txt ].
For in-depth analysis of keyboard drivers, refer to [ UDM-keyboard.txt ].
For in-depth analysis of video drivers, refer to [ UDM-video.txt ].
1) arch/blackfin/cpu/jtag-console.c
-----------------------------------
This driver is a classic STDIO driver, no problem with conversion is expected.
2) board/mpl/pati/pati.c
------------------------
This driver registers with the STDIO framework, though it uses a lot of ad-hoc
stuff which will need to be sorted out.
3) board/netphone/phone_console.c
---------------------------------
This driver is a classic STDIO driver, no problem with conversion is expected.
4) drivers/net/netconsole.c
---------------------------
This driver is a classic STDIO driver, no problem with conversion is expected.
IV) Other involved files (To be removed)
----------------------------------------
common/cmd_console.c
common/cmd_log.c
common/cmd_terminal.c
common/console.c
common/fdt_support.c
common/iomux.c
common/lcd.c
common/serial.c
common/stdio.c
common/usb_kbd.c
doc/README.iomux
|
