Re: [PATCH v5 3/6] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

On Mon, Apr 27, 2026 at 9:45 AM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 4/27/26 12:01 AM, Aaron Kling wrote:
> > On Fri, Apr 24, 2026 at 7:11 AM Konrad Dybcio
> > <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> >>
> >> On 4/8/26 9:41 PM, Aaron Kling via B4 Relay wrote:
> >>> From: Teguh Sobirin <teguh@xxxxxxxx>
> >>>
> >>> This contains everything common between the AYN QCS8550 devices. It will
> >>> be included by device specific dts'.
> >>>
> >>> Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
> >>> Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> >>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> >>> ---
>
> [...]
> >>> +&pm8550_gpios {
> >>> +     fan_pwm_active: fan-pwm-active-state {
> >>> +             pins = "gpio8";
> >>> +             function = "func1";
> >>> +             input-disable;
> >>> +             output-enable;
> >>> +             output-low;
> >>
> >> Looks like this should be a regulator then, probably?
> >
> > Mmm, what would it be tied to, then? The fan already has a reg. I
> > presume just modeling it as an always on reg tied to nothing is
> > undesirable. I also have no idea what the voltage would be.
>
> Or maybe it's some sort of reset/enable GPIO. Or an enable pin to
> whatever feeds into VDD_FAN_5V0. It's hard to tell indeed.

Talking to someone working on the downstream kernel for these devices,
the purpose of this is to set the pin to 'func1' or pwm4 output. It's
not a regulator or reset or something that needs otherwise modeled.

> >
> >> [...]
> >>
> >>> +     wcd_default: wcd-reset-n-active-state {
> >>> +             pins = "gpio108";
> >>> +             function = "gpio";
> >>> +             drive-strength = <16>;
> >>> +             bias-disable;
> >>> +             output-low;
> >>
> >> no need for this property
> >
> > I'll start with saying that I know basically nothing about qcom
> > hardware design and what the average pinmuxing layout looks like. But
> > I do note that a lot of existing devices have this exact same node,
> > for example the sm8550 hdk [0]. Is there something that makes these
> > devices different? Or is this unnecessary everywhere?
>
> That's my understanding.
>
> [...]
>
> >>> +     usb0_sbu_default: usb0-sbu-state {
> >>> +             oe-n-pins {
> >>> +                     pins = "gpio140";
> >>> +                     function = "gpio";
> >>> +                     bias-disable;
> >>> +                     drive-strength = <16>;
> >>> +                     output-high;
> >>
> >> This is probably not required too.. unless there's a hw bug?
> >>
> >> fwiw 16 mA is a very high drive-strength - does this come from vendor
> >> sources?
> >
> > I do not see any pinmux for gpio140 in the downstream dt or anything
> > matching pi3usb102 at all, I'm not sure how it's handled there. The
> > original source of this dt was written before there was a public gpl
> > code release from AYN. I do see other qcom users of the pi3usb102
> > doing similar however, for example the sc8280xp crd [1]. So I've got
> > the same question as above: is there something different here, or is
> > it possible other existing copies of this are also wrong?
>
> You can retrieve the settings from your device at runtime,
> /sys/kernel/debug/gpio will read back the hw settings
>
> As for the CRD, I don't know. It may as well be board-specific.

I got pointed in the right direction to see this on downstream. The
active drive strength on gpio140/141 is 8. Does this seem more
reasonable?

Aaron