Hi Linus,
I'm working on adding support to the cp210x driver for the optional GPIO
pins available on Silicon Labs CP2105 USB to serial bridge.
Some hardware implementation details have got me wondering how best to
provide support through the GPIO framework.
The device has 5 pins that can be GPIO. The pins that provide these GPIO
are muxed with serial control signals of the 2 serial ports the device
provides, though the GPIO is enabled by default.
The GPIO pins can be configured as either push-pull or open-drain, with
a internal weak pullup. The pins are open-drain by default. There is no
explicit "input" mode, though it is possible to sense the state of the
pin independent of the state being driven.
Configuration of the muxing and GPIO mode is stored in one-time
programmable PROM built into the chip and can't be changed at runtime.
The muxing is done for all pins associated with a port in one go. I
think I can determine at runtime when pins are used as serial control
signals, so currently have the pins split into 2 banks (each bank
providing the GPIO from pins associated with a port).
I believe I can also determine when pins are configured as push-pull or
open-drain. Pins configured as push-pull clearly can't be used as
inputs. Pins in open-drain mode, if not internally pulled to ground,
could be used as an input.
I can allow open-drain pins to be configured as input (and arrange for
the pin to not be pulled low when it is), but the GPIO documentation
suggests that the output state of GPIO should be able to be set prior to
switching between input and output mode. This could be achieved by
storing a bit masks of values and directions, however this would require
locking to avoid race conditions and the documentation also suggests
that locking should be avoided in the get, set and direction functions,
so that the drivers can be used by and -RT kernel (I appreciate this a
USB device, so less likely to be used in a real time context).
If such a scheme really isn't suitable, alternatively the pins could be
output only, with the user still being able to sense the pin state as
long as the pin is not set to pull the pin low. The disadvantage of not
allowing the pins to be configured as input is that users will
(ironically) not be able to use one of the pins with the
"GPIOF_OPEN_DRAIN" flag set as this attempts to set the pin as input
instead of a high state. "GPIOF_OPEN_SOURCE" is broken on this hardware
either way.
How do you think it would be best to proceed?
Martyn
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
