Is it possible to use the kernel driver for OPD MAX7310 GPIO?

[ThirteenFish]

The kernel has a driver for the MAX7310 over I2C (gpio-pca953x) so we could just use that for the OPD GPIO lines. Two questions to answer before doing that though:

• What features, if any, do we lose from interacting with the MAX7310 directly?
• How does the driver handle hotplugging the chips. We'll be adding and removing cards without rebooting the C3 while on the flatsat/engineering unit. Does the driver handle the chips disappearing and reappearing gracefully or does it break things?

[CullenSharp]

I can take a look at this.

[CullenSharp]

I was speaking to @etsoi1 about this, and I think I have a pretty good idea about the role that the MAX7310 has for OPD. I think I need a little more context though.

How does the C3 currently interface with the MAX7310?

[ThirteenFish]

The C3 currently uses them as I2C devices directly from userspace (driver here). It still sets and clears gpio lines but does this by doing an I2C transaction to the MAX3710 registers instead of something like the gpiod interface.

It used to be that one MAX corresponded to one card so it wasn't the worst that we viewed opd on the chip level instead of the port level, but the current iteration has some MAXes controlling the function of multiple cards. From the functional perspective the OPD is now more a bunch of GPIO with arbitrary function than it is a collection of I2C devices.

[CullenSharp]

Just want to double check if the gpio-pca935x was configured for our kernel; it is.

CONFIG_GPIO_PCA953X=m

Found an example in the device tree for this:

...

powerdown-gpios = <&max7310_b 2 GPIO_ACTIVE_LOW>;

...

max7310_b: gpio@32 {
	compatible = "maxim,max7310";
	reg = <0x32>;
	gpio-controller;
	#gpio-cells = <2>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_max7310>;
	reset-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
};

...

pinctrl_max7310: max7310grp {
	fsl,pins = <
		MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x1b0b0
	>;
};

[CullenSharp]

This is actually a more useful example: gpio-pca95xx/max-73xx dt-binding.

Figuring out pinctrl for this at the moment.

[CullenSharp]

I'm gonna run this down a bit more, but here are my initial findings.

I added all the max7310 devices to the C3 device tree, and booted it without any auxiliary cards plugged in.

The max7310 devices probe early in the boot process:

[    3.850303] pca953x 2-0010: supply vcc not found, using dummy regulator
[    3.850634] pca953x 2-0010: using no AI
[    3.864346] pca953x 2-0010: failed writing register: -121
[    3.864681] pca953x 2-0010: probe with driver pca953x failed with error -121

Anyways, I don't see anything in the pca953x driver that supports hotplugging. This is probably fine, right? The only apparent downside is the need to reboot the c3 everytime we add a card to flatsat. Maybe I'm missing something.

PS: From the second line, I see that it's using a non-auto-increment regmap^{1 2}. I liked this article on the topic of the regmap API. Incidentally, maybe I should integrate regmap into the prucam module.

Footnotes

1. https://lwn.net/Articles/451789/ ↩

2. https://elixir.bootlin.com/linux/v6.12.34/source/include/linux/regmap.h ↩

[CullenSharp]

Got it to work. to all devices on on the i2c-2 bind on flatsat.

1. Pull OPD_nENABLE low
2. Bind all devices to the pca953x driver

#!/usr/bin/bash -e

# enable OPD_nENABLE
gpioset --daemonize --chip 2 --by-name OPD_nENABLE=0 

devices=(/sys/bus/i2c/devices/i2c-2/2-*)
if [ ! -e "${devices[0]}" ]
then 
    echo "No devices registered for the i2c-2 bus"
    exit 1
fi

for device in "${devices[@]}"
do
    # bind driver to device
    echo $(basename "${device}") > /sys/bus/i2c/drivers/pca953x/bind
done

to unbind

#!/usr/bin/bash -e

# enable OPD_nENABLE
gpioset --daemonize --chip 2 --by-name OPD_nENABLE=0 

devices=(/sys/bus/i2c/devices/i2c-2/2-*)
if [ ! -e "${devices[0]}" ]
then 
    echo "No devices registered for the i2c-2 bus"
    exit 1
fi

devices=(/sys/bus/i2c/devices/i2c-2/2-*)
for device in "${devices[@]}"
do
    # unbind driver to device
    echo $(basename "${device}") > /sys/bus/i2c/drivers/pca953x/unbind
done

[CullenSharp]

Additional findings, it's currently not working through the shell. I tried to use gpioset to boot the star tracker remotely by pulling sysboot and the enable pin high. This should have caused the card to boot, acquire a DHCP lease, and appear on the LAN, but no luck.

The UX for this is also terrible. It's really hard to tell which chip is attached to which OPD node, so my next step was to write a udev rule that symlinks each node by address (e.g. /dev/gpio/by-addr/gpiochip-2-1c -> /dev/gpiochipN). Probably something similar for the SOC gpio banks would be nice.

I'll have to get in the lab to probe the circuit and see what's happening. Maybe gpioset is too dumb. Maybe I should try using python3-gpiod instead.

[CullenSharp]

I was tinkering with this again, thinking that maybe output polarity was the issue. I wrote a short script to dump the registers for the CFC processor (0x1d) and Star Tracker (0x1c). The CFC processor's max7310 is in it's default powered on state, whereas the star trackers has been manipulated with gpioset. lines 0,4,5 (sysboot, enable, cb reset) were set high.

Edit: AI helped me write a slightly better bash util

#!/usr/bin/bash
set -euo pipefail

usage() {
  echo "Usage: $0 <i2c_address>"
  echo "Example: $0 0x1c"
  exit 1
}

# Require exactly one argument
[[ $# -eq 1 ]] || usage

addr="$1"

# Validate hex format
if [[ ! "$addr" =~ ^0x[0-9a-fA-F]{1,2}$ ]]; then
  echo "Error: address must be a 1-byte hex value"
  exit 1
fi

# Convert to decimal for range check
addr_dec=$((addr))

# Valid range: 0x08 - 0x25
if ((addr_dec < 0x08 || addr_dec > 0x25)); then
  echo "Error: address must be between 0x08 and 0x25"
  exit 1
fi

# Register map
declare -A REG_NAMES=(
  [0]="INPUT"
  [1]="OUTPUT"
  [2]="POLARITY"
  [3]="CONFIGURATION"
  [4]="TIMEOUT"
)

printf "Showing device 0x%02X\n" "${addr}"
printf "############################\n"
for reg in "${!REG_NAMES[@]}"; do
  value=$(i2cget -y 2 "${addr}" "${reg}" i 1)
  printf "0x%02X %-16s = %s\n" "$reg" "${REG_NAMES[$reg]}" "$value"
done

Showing device 0x1C
############################
0x04 TIMEOUT          = 0x01
0x03 CONFIGURATION    = 0xe6
0x02 POLARITY         = 0x00
0x01 OUTPUT           = 0x19
0x00 INPUT            = 0x1c

Showing device 0x1D
############################
0x04 TIMEOUT          = 0x01
0x03 CONFIGURATION    = 0xff
0x02 POLARITY         = 0xf0
0x01 OUTPUT           = 0x00
0x00 INPUT            = 0xf4

	input	output	polarity	configuration	timeout
star tracker	0x1c	0x19	0x00	0xe6	0x01
cfc	0xf4	0x00	0xf0	0xff	0x01

So I notice a few things:

• outputs are set correctly. 0x19 => lines 0,4,5 are set to active
• polarity is correct; that is all lines are active high.
• direction is being set correctly. 0xe6 => lines 0,4,5 are set as outputs

But noticeably, the configuration remains even after releasing the pin. This implies to me that pins will need to be explicitly driven low and set as inputs to turn them off.

[CullenSharp]

Updates! I'm able to boot the GPS card, though not the star tracker. I'm moving on to the OPD refactor now. Here's my initial thoughts:

• i2c devices should be bound on service start
• a udev rule will symlink each chip to a path like /dev/opd/gpiochip-2-1c
• the opd should be left mostly intact replacing just the max7310.py driver with gpiod