UMCPMIO(4) | Device Drivers Manual | UMCPMIO(4) |
umcpmio
—
umcpmio* at uhidev? reportid ?
gpio* at gpiobus?
iic* at umcpmio? or
iic* at i2cbus?
umcpmio
driver provides support for the MCP2221 /
MCP2221A multi-io bridge chip. The chip provides 4 simple gpio pins with
multiple functions that attach as a
gpio(4) device, an I2C port that
attaches as an iic(4) device and a
UART serial port that attaches using
umodem(4) as a normal
ucom(4)
ttyU* device. The UART is
presented as one USB function, while the GPIO and I2C pins are presented as a
second HID USB function.
Assignment | GP0 | GP1 | GP2 | GP3 |
GPIO | GPIO | GPIO | GPIO | GPIO |
ALT0 | UART RX | ADC1 | ADC2 | ADC3 |
ALT1 | - | UART TX | DAC1 | DAC2 |
ALT2 | - | IRQ | - | - |
ALT3 | SSPND | Clock output | USBCFG | I2C activity |
ADC1, ADC2 and ADC3 are independent of each other and each 10 bits
in length. To utilize one of the ADC pins, an
open(2) is performed against
/dev/umcpmio0GP1,
/dev/umcpmio0GP2 or
/dev/umcpmio0GP3 with only the
O_RDONLY
flag set. Reads against the open file
descriptor will produce uint16_t values.
There is actually only one DAC present in the chip, but it is
mirrored to GP2 and GP3 if the pin is set to ALT1. The DAC is 5 bits in
length, and to use it, an
open(2) is performed against
/dev/umcpmio0GP2 or
/dev/umcpmio0GP3 with only the
O_WRONLY
flag set. Writes of
uint8_t bytes to the file descriptor will result in an
analog signal being created on the output pin.
The clock output is derived from the USB clock of 48MHz. The duty cycle and clock divider can be adjusted with sysctl(8) variables. To utilize GP1 as the clock output, the ALT3 function can be set with gpioctl(8) command.
The MCP2221 / MCP2221A chip will automatically detact and deal with a device that uses I2C clock stretching.
hw.umcpmio0.debug
hw.umcpmio0.dump_buffers
UMCPMIO_DEBUG
is defined, additional debugging
output can be enabled.
hw.umcpmio0.response_wait
hw.umcpmio0.response_errcnt
response_errcnt
number of
errors when waiting for a reponse from a HID report. This includes
timeouts due to exceeding response_wait
.
hw.umcpmio0.i2c.reportreadnostop
hw.umcpmio0.i2c.busy_delay
busy_delay
microseconds before checking
again.
hw.umcpmio0.i2c.retry_busy_read
hw.umcpmio0.i2c.retry_busy_write
hw.umcpmio0.gpio.clock_duty_cycle
hw.umcpmio0.gpio.clock_divider
clock_duty_cycle
are
‘75%
’,
‘50%
’,
‘25%
’, and
‘0%
’. That is, 75% of the time a
high and 25% of the time a low will be present on the GP1 pin. The valid
values for clock_divider
are
‘375kHz
’,
‘750kHz
’,
‘1.5MHz
’,
‘3MHz
’,
‘6MHz
’,
‘12MHz
’, and
‘24MHz
’.
hw.umcpmio0.dac.vref
hw.umcpmio0.adc.vref
4.096V
’,
‘2.048V
’,
‘1.024V
’,
‘OFF
’, and
‘VDD
’.umcpmio
driver first appeared in
NetBSD 11.0.
umcpmio
driver was written by Brad
Spencer
<brad@anduin.eldar.org>.
The interrupt function on GP1 cannot currently be used because it is currently not possible to attach through the driver. There may be two possible problems going on:
IPL_VM
with a spin lock and when it attempts to
establish an interrupt that uses the gpio from
umcpmio(4), calls are made
into the USB stack that will want to wait in a way that is not allowed
while holding a spin lock.KERNEL_LOCK
and during the attachment, this lock
is held when calls are made into the USB stack that will cause a wait that
is not allowed while holding KERNEL_LOCK
.Either or both of these may be going on, but the end result is that the kernel will panic while attempting to perform a USB transfer while another driver is attempting to attach through umcpmio(4).
Likewise, a ‘gpioctl gpio1 attach
...
’ type call will also panic for the same reason.
The end result is that gpioirq(4), gpiopps(4) and gpioow(4) will not work with the gpio from umcpio(4).
Please note that the umcpmio(4) driver itself can use the USB stack during attachment and there does not appear to be any problems using the GPIO pins or setting GPIO pin configurations. It is only when the driver is a target during another driver's attachment that there is a problem.
The ability to set or change values in most of the chip's FLASH memory is not supported. This includes changing the configuration protection password. Likewise, support for entering the configuration protection password does not exist, should a particular chip have password protection enabled.
December 16, 2024 | NetBSD 10.99 |