About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / arm / msm / gpiomux.txt


Based on kernel version 4.0. Page generated on 2015-04-14 21:19 EST.

1	This document provides an overview of the msm_gpiomux interface, which
2	is used to provide gpio pin multiplexing and configuration on mach-msm
3	targets.
4	
5	History
6	=======
7	
8	The first-generation API for gpio configuration & multiplexing on msm
9	is the function gpio_tlmm_config().  This function has a few notable
10	shortcomings, which led to its deprecation and replacement by gpiomux:
11	
12	The 'disable' parameter:  Setting the second parameter to
13	gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral
14	processor in charge of the subsystem to perform a look-up into a
15	low-power table and apply the low-power/sleep setting for the pin.
16	As the msm family evolved this became problematic. Not all pins
17	have sleep settings, not all peripheral processors will accept requests
18	to apply said sleep settings, and not all msm targets have their gpio
19	subsystems managed by a peripheral processor. In order to get consistent
20	behavior on all targets, drivers are forced to ignore this parameter,
21	rendering it useless.
22	
23	The 'direction' flag: for all mux-settings other than raw-gpio (0),
24	the output-enable bit of a gpio is hard-wired to a known
25	input (usually VDD or ground).  For those settings, the direction flag
26	is meaningless at best, and deceptive at worst.  In addition, using the
27	direction flag to change output-enable (OE) directly can cause trouble in
28	gpiolib, which has no visibility into gpio direction changes made
29	in this way.  Direction control in gpio mode should be made through gpiolib.
30	
31	Key Features of gpiomux
32	=======================
33	
34	- A consistent interface across all generations of msm.  Drivers can expect
35	the same results on every target.
36	- gpiomux plays nicely with gpiolib.  Functions that should belong to gpiolib
37	are left to gpiolib and not duplicated here.  gpiomux is written with the
38	intent that gpio_chips will call gpiomux reference-counting methods
39	from their request() and free() hooks, providing full integration.
40	- Tabular configuration.  Instead of having to call gpio_tlmm_config
41	hundreds of times, gpio configuration is placed in a single table.
42	- Per-gpio sleep.  Each gpio is individually reference counted, allowing only
43	those lines which are in use to be put in high-power states.
44	- 0 means 'do nothing': all flags are designed so that the default memset-zero
45	equates to a sensible default of 'no configuration', preventing users
46	from having to provide hundreds of 'no-op' configs for unused or
47	unwanted lines.
48	
49	Usage
50	=====
51	
52	To use gpiomux, provide configuration information for relevant gpio lines
53	in the msm_gpiomux_configs table.  Since a 0 equates to "unconfigured",
54	only those lines to be managed by gpiomux need to be specified.  Here
55	is a completely fictional example:
56	
57	struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
58		[12] = {
59			.active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1,
60			.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
61		},
62		[34] = {
63			.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
64		},
65	};
66	
67	To indicate that a gpio is in use, call msm_gpiomux_get() to increase
68	its reference count.  To decrease the reference count, call msm_gpiomux_put().
69	
70	The effect of this configuration is as follows:
71	
72	When the system boots, gpios 12 and 34 will be initialized with their
73	'suspended' configurations.  All other gpios, which were left unconfigured,
74	will not be touched.
75	
76	When msm_gpiomux_get() is called on gpio 12 to raise its reference count
77	above 0, its active configuration will be applied.  Since no other gpio
78	line has a valid active configuration, msm_gpiomux_get() will have no
79	effect on any other line.
80	
81	When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference
82	count to 0, their suspended configurations will be applied.
83	Since no other gpio line has a valid suspended configuration, no other
84	gpio line will be effected by msm_gpiomux_put().  Since gpio 34 has no valid
85	active configuration, this is effectively a no-op for gpio 34 as well,
86	with one small caveat, see the section "About Output-Enable Settings".
87	
88	All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but
89	they address some important issues.  As unused entries (all those
90	except 12 and 34) are zero-filled, gpiomux needs a way to distinguish
91	the used fields from the unused.  In addition, the all-zero pattern
92	is a valid configuration!  Therefore, gpiomux defines an additional bit
93	which is used to indicate when a field is used.  This has the pleasant
94	side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate
95	that a value should not be changed:
96	
97	  msm_gpiomux_write(0, GPIOMUX_VALID, 0);
98	
99	replaces the active configuration of gpio 0 with an all-zero configuration,
100	but leaves the suspended configuration as it was.
101	
102	Static Configurations
103	=====================
104	
105	To install a static configuration, which is applied at boot and does
106	not change after that, install a configuration with a suspended component
107	but no active component, as in the previous example:
108	
109		[34] = {
110			.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
111		},
112	
113	The suspended setting is applied during boot, and the lack of any valid
114	active setting prevents any other setting from being applied at runtime.
115	If other subsystems attempting to access the line is a concern, one could
116	*really* anchor the configuration down by calling msm_gpiomux_get on the
117	line at initialization to move the line into active mode.  With the line
118	held, it will never be re-suspended, and with no valid active configuration,
119	no new configurations will be applied.
120	
121	But then, if having other subsystems grabbing for the line is truly a concern,
122	it should be reserved with gpio_request instead, which carries an implicit
123	msm_gpiomux_get.
124	
125	gpiomux and gpiolib
126	===================
127	
128	It is expected that msm gpio_chips will call msm_gpiomux_get() and
129	msm_gpiomux_put() from their request and free hooks, like this fictional
130	example:
131	
132	static int request(struct gpio_chip *chip, unsigned offset)
133	{
134	        return msm_gpiomux_get(chip->base + offset);
135	}
136	
137	static void free(struct gpio_chip *chip, unsigned offset)
138	{
139	        msm_gpiomux_put(chip->base + offset);
140	}
141	
142		...somewhere in a gpio_chip declaration...
143		.request = request,
144		.free    = free,
145	
146	This provides important functionality:
147	- It guarantees that a gpio line will have its 'active' config applied
148	  when the line is requested, and will not be suspended while the line
149	  remains requested; and
150	- It guarantees that gpio-direction settings from gpiolib behave sensibly.
151	  See "About Output-Enable Settings."
152	
153	This mechanism allows for "auto-request" of gpiomux lines via gpiolib
154	when it is suitable.  Drivers wishing more exact control are, of course,
155	free to also use msm_gpiomux_set and msm_gpiomux_get.
156	
157	About Output-Enable Settings
158	============================
159	
160	Some msm targets do not have the ability to query the current gpio
161	configuration setting.  This means that changes made to the output-enable
162	(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux.
163	Therefore, when gpiomux applies a configuration setting, any direction
164	settings which may have been applied by gpiolib are lost and the default
165	input settings are re-applied.
166	
167	For this reason, drivers should not assume that gpio direction settings
168	continue to hold if they free and then re-request a gpio.  This seems like
169	common sense - after all, anybody could have obtained the line in the
170	meantime - but it needs saying.
171	
172	This also means that calls to msm_gpiomux_write will reset the OE bit,
173	which means that if the gpio line is held by a client of gpiolib and
174	msm_gpiomux_write is called, the direction setting has been lost and
175	gpiolib's internal state has been broken.
176	Release gpio lines before reconfiguring them.
Hide Line Numbers


About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog