I’ve been enjoying cutting my teeth on the Zero as my first sbc. I’ve a long history as a linux sysadmin and it’s impressive to see what’s possible in this form factor.
I generated my first overlay a week ago but am yet to find comprehensive docs to translate kernel device details into overlay source.
Does anybody know the correct syntax to specify gpio drive strength (ie: current output) via an overlay?
@RadxaYuntian shared this link, which provides some naming specifics:
More precisely, I’m looking to increase GPIOAO_3 drive-strength-microamp from 500 to 2000uA.
I’ve been reading about this for more than a week and have found reference to syntax like: drive-strength-microamp = <2000>;
The missing piece is what needs to precede and close this statement. After reading the Radxa S905Y2 manual then this pin primer and looking at the example from the above meson pinctrl bindings along with all the overlay source files and dtsi definitions, the mystery is how to refer to the pin group specific to the amlogic,g12a
/dts-v1/;
/plugin/;
/ {
compatible = "radxa,zero", "amlogic,g12a";
fragment@0 {
target = <&GPIOAO_3>; # this is a guess from the driver def
__overlay__ {
status = "okay";
pinctrl-0 = <&GPIOAO_3_pins>; # this is an extrapolation from the above & other DTSes
pinctrl-names = "default";
drive-strength-microamp = <2000>;
};
};
};
Any overlay overlords out there with some insights?
Does reveal a new file: /sys/firmware/devicetree/base/soc/bus@ff800000/sys-ctrl@0/pinctrl@14/drive-strength-microamp
The file is of type ‘data’ so is not human readable and differs from other firmware/devicetree entries for drive-strength-microamp.
Unfortunately the output is still indicated as 500uA in the pinconf-pins file: /sys/kernel/debug/pinctrl/ff800000.sys-ctrl\:pinctrl@14-pinctrl-meson/pinconf-pins
Reviewing meson-g12-common.dtsi seems to show a mux { } statement prior to setting drive-strength and other overlay source files seem to all indicate the specific pin group based on pinctrl-0 = statements.
Please provide an updated dts including the pin group needed to successfully set the drive strength for ao?
I noticed that but thought there may be a conflict calling two overlays for GPIOAO-3: meson-g12a-i2c-ao-m0-gpioao-2-gpioao-3
AND meson-g12a-w1-gpioa-3-high
Is it okay to call both of these overlays together?
Calling the first overlay does result in the drive strength showing 3000uA from the pinconf-pins output: pin 2 (GPIOAO_2): input bias disabled, output drive strength (3000 uA) pin 3 (GPIOAO_3): input bias disabled, output drive strength (3000 uA)
I lost track of your issue and thought you were using i2c. The way you use overlays might give you issue since 2 functions are defined on the same pin.
If that’s the case you probably need to find a way to incorporate this section into your w1 overlay. You can keep the group line since that name is just a label, but for function line I think you need to specify gpio_aobus. That should be the proper way to handle this.
Unfortunately, neither changed the drive strength reported in: /sys/kernel/debug/pinctrl/ff800000.sys-ctrl\:pinctrl@14-pinctrl-meson/pinconf-pins
Are there any additional includes required for the second fragment?
Or perhaps an alternate pin group needs to be specified which includes GPIOAO_3 and also the pad it is on?
As I work in a factory, the industrial applications for supporting parasitic power for onewire sensors is huge. The Zero serving as the building heat controller is the first proof of concept.
Look forward to your thoughts and hope your week is going well!
Thank you @RadxaYuntian, I tested the second stub on its own as a fragment@0 overlay and unfortunately still didn’t see any change in the reported pinctrl drive strength.
At this point I need to finalize this project, so I may either directly connect the DS18B20 sensors to an ESP32 over onewire or drive them from a spare Shelly 1 with a temp sensor connector.
I really appreciate your guidance in getting onewire working on the Zero and with attempting to modify the GPIO drive strength.
The Zero will likely continue to serve as the HomeAssistant server, which will allow additional integrations down the line.
I’ll be sure to share my BoM and results once everything’s set.