nrst_pulse toggle in rtl8196e_uart_bridge_main.c

[hlyi]

Hi @jnilo1, since #119 has overloaded information, I am starting a new thread dedicated to uart bridge.

It seems to me that nrst_pulse implementation in rtl8196e_uart_bridge_main.c can be improved:

1. it changes settings for 3 GPIOs, but nrst is only connected to one GPIO. they could be effective by doing so.
2. the mechanism of toggle nrst seems to be non-ideal, it changes MUX_SEL, I think it would be better just change the output level of the pin.
3. avoid hardcoded GPIO number. The IO number can come from parameter or argument (later on this)

Thanks

[jnilo1]

Hi @hlyi — you were right on all three counts. I took this through the bench today; here is what came out, and what changed.

What the bench says

The three bits {7,10,13} the driver flipped are the high bits of three distinct 2-bit pin-mux fields in PIN_MUX_SEL_2 (0xb8000044): [7:6] = pad B4 (GPIO line 12), [10:9] = B5 (line 13), [13:12] = B6 (line 14). The 0x2480 mask was copied wholesale from the chip's reset-default value back when we root-caused the "radio held in reset" problem — it had never been isolated per field.

Pulsing each bit individually on a live gateway (NCP firmware, watching TCP:8888 for the spontaneous reset frame the EFR32 emits when it boots):

bit set	mux field	pad / GPIO line	EFR32 resets?
7	[7:6]	B4 / 12	yes
10	[10:9]	B5 / 13	no
13	[13:12]	B6 / 14	no

So on the Lidl board nRST is wired to pad B4 = line 12 of the gpio-rtl819x chip, and the other two fields were just being re-routed for 100 ms on every pulse — exactly as you suspected.

New implementation (bridge driver v1.1)

nrst_pulse now claims that one line through the gpiod consumer API with open-drain semantics:

• assert = drive the pad low (output 0);
• release = float the line back to input and let the EFR32's internal RESETn pull-up raise it. RESETn is never driven high.

The pad mux to GPIO mode (field value 0b11) is applied automatically by the gpio-rtl819x request() hook, so the bridge no longer touches the syscon at all. The line is claimed per pulse and released afterwards.

The knob you asked for

The line number is a new runtime-writable parameter:

cat /sys/module/rtl8196e_uart_bridge/parameters/nrst_gpio    # 12 (Lidl default)
echo <line> > /sys/module/rtl8196e_uart_bridge/parameters/nrst_gpio
echo 1 > /sys/module/rtl8196e_uart_bridge/parameters/nrst_pulse

It takes effect on the next pulse, so you can probe candidate lines from a shell without rebuilding anything. Errors come back through the write: EBUSY if the line is already claimed (e.g. the status LED on line 11), EINVAL outside 0–31.

One caveat for your port: gpio-rtl819x only auto-muxes pads B2–B6 (lines 10–14, the LED_PORT fields of PIN_MUX_SEL_2). If the G4's nRST pad sits outside that range, the pad mux has to be established separately — extending rtl819x_gpio_configure_pinmux() in gpio-rtl819x.c is the right place, and I'd take that patch.

Verification

On the bench (v3.9.0 WIP kernel): same reset signature as the old mechanism; invalid parameter values rejected; a pulse on a wrong-but-free line runs without resetting the radio; two concurrent pulses serialize cleanly; the TCP client stays connected across the pulse; recover_efr32 and flash_efr32.sh work unchanged; iperf3 RX/TX unchanged (93.5 / 69.0 Mbit/s).

The change ships in v3.9.0, just released (kernel-only reflash). Thanks for the push — this knob had been carrying its empirical scaffolding since v3.1.

[hlyi]

@jnilo1 Thanks for your super fast change!

Since nrst is fixed for a given platform, do you think we can specify the nrst GPIO via device-tree?

Also, I have an additional request that needs your help: for a different platform, it has a different way to enter bootloader mode: addition pin, say blmode, is sampled at de-assertion of nrst. I think it is also open drain, active signal that similar to nrst. In another word, in normal operation mode, blmode will be pull-up. When requesting entering bootloader mode, blmode will be hold low, then toggle nrst pin from low to high. After 6 seconds, the blmode can be released. For platform doesn't support blmode pin, we can set the pin number to -1. what do you think?

Thanks again.

[hlyi]

This request has been fulfilled with the latest v3.11.0-pre branch. Closing.