On 14/01/16 09:24, Linus Walleij wrote:
On Wed, Jan 13, 2016 at 5:10 PM, Martyn Welch
<martyn.welch@xxxxxxxxxxxxxxx> 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@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.
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
--
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
