On 13/01/16 14:58, Linus Walleij wrote:
(Adding Johan Hovold, serial-usb-maintainer)
On Fri, Jan 8, 2016 at 12:14 PM, Martyn Welch
<martyn.welch@xxxxxxxxxxxxxxx> wrote:
I'm working on adding support to the cp210x driver for the optional GPIO
pins available on Silicon Labs CP2105 USB to serial bridge.
Do you have a data sheet?
Yes.
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.
I don't get it? Do you mean that the two serial ports will be able on
some serial port pins and then *also* on these extra pins in this
case, or do you mean that this is the only way for the serial
lines to get out of the chip?
You loose DTR, DSR, DCD and RI on each serial port when GPIO is enabled
on that port. Two of these pins on one port and 3 on the other become
GPIO. Both serial ports are still available, but only provide TX, RX,
RTS and CTS (which is more than enough for a lot of uses).
In any case, multiplexing is really a task for the pin control
framework, if you desire to switch this muxing at runtime.
You can't do it at runtime. The choice is programmed into a PROM,
typically at manufacture time (OEM, not chip) and can't be reverted.
If you don't ever want to change the muxing from the default, just don't
implement muxing and us it as-is.
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.
OK so no high impedance input state?
Correct.
These modes are better controlled by pin control, but if you
have only these modes, the GPIO subsystem will suffice.
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.
OK no runtime muxing then.
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.
OK how do you determine this then?
There are some vendor specific USB calls that can be used to determine this.
Isn't it possible to read/query the PROM about the settings?
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.
I don't think there is such a rule. We cannot dictate how hardware
works. Seems like good hardware design, but it is really not our
pick.
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).
I don't quite get this. The talk about the RT kernel is about irqchips.
This adapter doesn't support interrupts does it?
Ah, OK. Miss-understood the documentation.
For gpio_chips, see the flag .can_sleep.
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.
I think this problem goes away if you look closely.
Yours,
Linus Walleij
Thanks for your reply,
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
