CP2105 GPIO Pins

CP2105 GPIO Pins

[Martyn Welch]

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

Re: CP2105 GPIO Pins

[Linus Walleij]

(Adding Johan Hovold, serial-usb-maintainer)

On Fri, Jan 8, 2016 at 12:14 PM, Martyn Welch
<martyn.welch@collabora.co.uk> 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

Re: CP2105 GPIO Pins

[Martyn Welch]

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@collabora.co.uk> 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

Re: CP2105 GPIO Pins

[Linus Walleij]

On Wed, Jan 13, 2016 at 5:10 PM, Martyn Welch
<martyn.welch@collabora.co.uk> wrote:
> 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@collabora.co.uk> 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.

So can you share it or is it online somewhere?

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

OK modem signals go out the window and instead these pins
are used for GPIO, because noone is using modems any more.
Makes perfect sense.

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

OK then you should just go with the manufacturing setup
and you probably do not need pin control at all.

>> OK how do you determine this then?
>
> There are some vendor specific USB calls that can be used to determine this.

OK fair enough.

>> Isn't it possible to read/query the PROM about the settings?

And I guess that is what it does.

Looking forward to the patch :)

Yours,
Linus Walleij

Re: CP2105 GPIO Pins

[Martyn Welch]

On 14/01/16 09:24, Linus Walleij wrote:
> On Wed, Jan 13, 2016 at 5:10 PM, Martyn Welch
> <martyn.welch@collabora.co.uk> wrote:
>> 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@collabora.co.uk> 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.
>
> So can you share it or is it online somewhere?
>

FWIW, It's online:

https://www.silabs.com/Support%20Documents/TechnicalDocs/CP2105.pdf

Unfortunately it isn't particularly informative when it comes to the 
gpio, though they do provide a driver (which uses custom ioctls in the 
serial device, ick) and a user space test application that gives a good 
idea of how to drive it (well, how to toggle all of the bits 
simultaneously anyway).

For the vendor specific stuff, they provide further code to enable the 
manufacturing programming which makes use of that. With a little bit of 
digging I was able to ascertain what codes were sent to retrieve the 
information I required and which bits of the returned value were 
important for my use case.

Martyn

>>> 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).
>
> OK modem signals go out the window and instead these pins
> are used for GPIO, because noone is using modems any more.
> Makes perfect sense.
>
>>> 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.
>
> OK then you should just go with the manufacturing setup
> and you probably do not need pin control at all.
>
>>> OK how do you determine this then?
>>
>> There are some vendor specific USB calls that can be used to determine this.
>
> OK fair enough.
>
>>> Isn't it possible to read/query the PROM about the settings?
>
> And I guess that is what it does.
>
> Looking forward to the patch :)
>
> Yours,
> Linus Walleij
>