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
|
# GPIO toggling in ACPI AML for coreboot
## Table of contents
- Introduction
- Platform Interface
- Helper routines
- Implementation details
- Arguments and Local Variables Management
## Introduction
ACPI provides platform-independent interfaces enabling the operating
system to perform power management for devices as well as the entire
system. An operating system can simply call into Method()s implemented
by the interface to request different power management operations. In
order to be able to perform these operations, an interface might
require toggling of GPIOs. e.g. a touchscreen device interface might
require toggling of reset-gpio in order to take the device out of
reset or to put it back into reset.
Thus, any coreboot driver that implements such an ACPI interface might
require the ability to toggle GPIOs. However, toggling of GPIO is not
the same across different platforms and it will require the driver to
depend upon platform to do the required work. This document presents a
simple interface that can be used by any coreboot driver to generate
ACPI AML code for reading or toggling platform GPIOs.
## Platform Interface
All platforms that use drivers requiring ACPI AML code for GPIO
interactions need to be implement the following functions:
1. Return GPIO Rx value if it is acting as input
int acpigen_soc_read_rx_gpio(unsigned int gpio_num)
2. Return GPIO Tx value if it is acting as output
int acpigen_soc_get_tx_gpio(unsigned int gpio_num)
3. Set GPIO Tx value to 1 if it is acting as output
int acpigen_soc_set_tx_gpio(unsigned int gpio_num)
4. Set GPIO Tx value to 0 if it is acting as output
int acpigen_soc_clear_tx_gpio(unsigned int gpio_num)
Each of the above functions takes as input gpio_num which is the gpio
number that needs to be read or toggled and returns an integer which
is:
1. Error = -1
2. Success = 0
Above callback functions are chosen to be implemented in C rather than
adding them as AML code callbacks for the following reasons:
1. It is easier to add error prints in C which will inform the
developer that these callbacks are missing. It restricts debugging
to coreboot logs.
2. GPIO conversion from number to register offset can be easily done
in C by reusing implemented functions rather than adding all the
logic to AML code or depending upon complicated macros to be added
to device-tree.
3. Allows GPIO AML methods to be present under any device scope and
gives SoC the flexibility to call them without any restrictions.
## Helper routines
In order to relieve drivers of the task of implementing the same code
for enabling/disabling Tx GPIOs based on the GPIO polarity, helper
routines are provided which implement this common code and can be used
directly in the driver routines:
1. Enable Tx GPIO
int acpigen_enable_tx_gpio(struct acpi_gpio gpio)
2. Disable Tx GPIO
int acpigen_disable_tx_gpio(struct acpi_gpio gpio)
Both the above functions take as input struct acpi_gpio type and
return -1 on error and 0 on success. These helper routines end up
calling the platform specific acpigen_soc_{set,clear}_tx_gpio
functions internally. Thus, all the ACPI AML calling conventions for
the platform functions apply to these helper functions as well.
## Implementation Details
ACPI library in coreboot will provide weak definitions for all the
above functions with error messages indicating that these functions
are being used. This allows drivers to conditionally make use of GPIOs
based on device-tree entries or any other config option. It is
recommended that the SoC code in coreboot should provide
implementations of all the above functions generating ACPI AML code
irrespective of them being used in any driver. This allows mainboards
to use any drivers and take advantage of this common infrastructure.
Platforms are restricted to using Local5, Local6 and Local7 variables
only in implementations of the above functions. Any AML methods called
by the above functions do not have any such restrictions on use of
Local variables in AML code. Local0 is to be used for all get/read
functions to return values. This means that the driver code should not
make any assumptions about the values in Local5, Local6 and Local7
variables.
```
**Function** **Operation** **Return**
acpigen_soc_read_rx_gpio Generate ACPI AML code to Error = -1
read value of Rx in Local0. Success = 0
acpigen_soc_get_tx_gpio Generate ACPI AML code to Error = -1
get value of Tx in Local0. Success = 0
acpigen_soc_set_tx_gpio Generate ACPI AML code to Error = -1
set Tx to 1. Success = 0
acpigen_soc_clear_tx_gpio Generate ACPI AML code to Error = -1
set Tx to 0. Success = 0
```
Ideally, the operation column in the above table should use one or
more functions implemented by the platform in AML code library (like
gpiolib.asl). In the example below SPC0 and GPC0 need to be
implemented by the SoC in AML code library and they can be used by
acpi_soc_set_tx_gpio to read and set bit in the appropriate register
for the GPIO.
**acpigen_soc_set_tx_gpio**
uint64_t gpio_reg_offset = gpio_get_reg_offset(gpio_num);
/* Store (\_SB.GPC0(gpio_reg_offset, Local5) */
acpigen_write_store();
acpigen_emit_namestring(“\\_SB.GPC0”);
acpigen_write_integer(gpio_reg_offset);
acpigen_emit_byte(LOCAL5_OP);
/* Or (Local5, TX_BIT, Local5) */
acpigen_write_or(LOCAL5_OP, TX_BIT, LOCAL5_OP);
/* \_SB.SPC0(gpio_reg_offset, LOCAL5) */
acpigen_emit_namestring(“\\_SB.SPC0”);
acpigen_write_integer(gpio_reg_offset);
acpigen_emit_byte(LOCAL5_OP);
return 0;
**acpigen_soc_get_tx_gpio**
uint64_t gpio_reg_offset = gpio_get_reg_offset(gpio_num);
/* Store (\_SB.GPC0(gpio_reg_offset, Local5) */
acpigen_write_store();
acpigen_emit_namestring(“\\_SB.GPC0”);
acpigen_write_integer(gpio_reg_offset);
acpigen_emit_byte(LOCAL5_OP);
/*
* If (And (Local5, TX_BIT)) Store (One, Local0) Else Store (Zero,
* Local0)
*/
acpigen_write_if_and(Local5, TX_BIT);
acpigen_write_store_args(ONE_OP, LOCAL0_OP);
acpigen_pop_len();
acpigen_write_else();
acpigen_write_store_args(ZERO_OP, LOCAL0_OP);
acpigen_pop_len();
return 0;
These are reference implementations and the platforms are free to
implement these functions in any way they like. coreboot driver can
then simply call into these functions to generate ACPI AML code to
get/set/clear any GPIO. In order to decide whether GPIO operations are
required, driver code can rely either on some config option or read
device-tree to use any user-provided GPIOs.
## Arguments and Local Variables Management
Platform-defined functions can call methods using the same calling
conventions provided by AML code. However, use of Local Variables is
restricted to Local5, Local6 and Local7 unless they call into some
other method. Called method can use any Local variables, Local0 -
Local7. In case of functions expected to return back value to the
caller, this value is expected to be returned in Local0.
Driver code should not make any assumptions about the contents of
Local5, Local6 and Local7 across callbacks to SoC code. If it makes a
read or get call to SoC, the return value should be used from Local0
on return. However, if it makes a set or clear call to SoC, the value
in Local0 is undefined.
|
