Re: CP2105 GPIO Pins

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

(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?

> 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?

In any case, multiplexing is really a task for the pin control
framework, if you desire to switch this muxing at runtime.

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?

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?

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?

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
--
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