USB: serial: cp210x: Implement GPIO support for CP2102N

[Martyn Welch <martyn.welch@collabora.co.uk>]

On Wed, 2018-06-20 at 19:41 +0000, Karoly Pados wrote:
> Hi Martyn,
> 
> > The rationale for the pins being permanently configured as output
> > pins
> > is that these pins (at least on the cp2105) do not appear to
> > provide a
> > true input mode. They offer a "push-pull" mode (where the voltage
> > is
> > pulled directly to ground or supply rail) and an "open-drain" mode
> > (where the pin is weakly pulled high by an internal resistor and
> > can be
> > pulled to ground). Unless I missed something, there is no
> > tristate/high
> > impedance mode typically associated with a pin being used as input.
> 
> You didn't miss anything. It is the same for many (maybe all) SiLabs
> devices, in particular also for the cp2102n, which spawned this
> conversation.
> I sent in patches for its GPIO support, but in contrast to the
> cp2105,
> I try to emulate input mode by making sure that a pin is never pulled
> low
> when it is set as an input, and that you cannot set push-pull pins as
> inputs.
> The reason why you were invited is because we are trying to figure
> out which
> approach should be taken.
> 
> > Sure, you can use the open-drain mode as input as long as you
> > understand that the permanent pull up in the cp2015 might have an
> > impact on what you are reading. For example, if you have a signal
> > that
> > is externally weakly pulled down, it's going to depend on the
> > relative
> > resistances of the internal and external resistors as to what
> > voltage
> > the line rests at and therefore what state the line is considered
> > to be
> > in. This could stop things working if you naively think the cp2105
> > is
> > acting as a typical high-impedance input.
> 
> Here I argue the following multiple ways. First, I say that claiming
> that
> a pin which is used as an input is actually an output is not only
> confusing,
> but also much less correct than thinking of it as an input pin with a
> weak
> pullup to prevent floating signals. Second, the pullups - while not 
> explicitly listed in the datasheet - can be calculated from what is
> there, 
> and for the cp2105 are typically 132k, for the cp2102n even higher
> around 
> 165k. These are pretty weak pullups, so weak that they won't matter
> for
> the vast majority of applications as people rarely use pull-ups or
> pull-
> downs higher than 100k (not never, but rarely). So claiming that it
> can
> result in false expectation, while not completely wrong, is favoring
> the 
> needs of a few instead of the much more common practice.
> 
> Lastly, and maybe most importantly, I argue that calling everything
> an 
> "output" pin only in name does not actually avoid any design errors,
> as
> the same circuit that would case a false reading in one case would
> also
> cause the same false reading in the other, and the circuits are
> usually
> developed before the software. So it'll be too late anyway by the
> time 
> somebody realizes such a mistake. But on the contrary, it opens up
> more 
> opportunities for errors, because now you are open to software bugs
> that
> ignore a pin's direction because everything's an output either way
> even 
> when it really isn't, and think that they can treat it as
> as open-drain while for some reason it is in push-pull mode. Worse,
> even if it is in open-drain mode, it will only work with a specific
> output
> values - it must be high, which is not the default. With my
> proposal, 
> setting a pin's direction to "input" will make sure it cannot be
> actively 
> driven by the chip, avoiding such "misunderstandings" and errors,
> and 
> similar measures are also in place for the push-pull pins.
> 

Yeah, I'll go with that. :-)

> The only problem I can see is if there isn't a way for the cp2105 to 
> query the reset values of the pins (maybe there is, I just haven't 
> looked into it). Then I don't know how the direction could be 
> determined for an open-drain pin during initialization. But this is 
> solved for the cp2102n, and then it is a device-specific issue for 
> the cp2105, which shouldn't be forced onto other devices if we
> otherwise 
> decide the approach to be inferior.
> 

I'm pretty sure there is a way to determine the pin state, though
unfortunately I no longer have access to the HW to be able to test...

Martyn

> Karoly
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html