00:00 <aceridus> i2c_hid_of is trying to bind but complains about vdd regulators and Int IRQ: https://imgur.com/a/wmXoGoN dts: https://dpaste.com/6WDW4GZRA

00:04 <jenneron[m]> yeah you need to bind an interrupt

00:04 <jenneron[m]> like this https://gitlab.com/TravMurav/pmaports/-/commit/3a0f3b28109984d2b2737c85bc375092c571de3c#855efa45c81518983ffea118ebd7ad08e81e4a48_0_244

00:04 <jenneron[m]> aceridus: ^

00:06 <jenneron[m]> also, add a node in &tlmm to configure this pin as pull-up

00:07 <jenneron[m]> aceridus: like this https://dpaste.com/2NHXUVY7E

00:15 <aceridus> I thought I did define an interrupt with "interrupt = <&tlmm 320 IRQ_TYPE_LEVEL_LOW>;" is the problem that it needs to be interrupt-extended type or that I didn't have the gpio pin defined under &tlmm? Or both?

00:21 <aceridus> pinctrl is saying invalid group "gpio320". dmesg: https://imgur.com/a/DkzbdCA dts: https://dpaste.com/853NQG4ES

00:24 <aceridus> I am only guessing here, but it looks like interrupt pin 320 might be under &apps_smmu instead?

00:31 <jenneron[m]> I'm not sure, this pin may be called differently

00:31 <jenneron[m]> but yes, you probably want interrupt-extended

00:32 <jenneron[m]> actually 320 seems to big

00:33 <jenneron[m]> maybe dsdt has some offset

00:33 <aceridus> I was wonder about that value too because I see &tlmm { gpio-ranges = <&tlmm 0 0 120> }

00:51 <jenneron[m]> yeah it can't be 320

00:52 <jenneron[m]> this is keyboard code in dsdt https://dpaste.com/37J7BJXNH

00:52 <jenneron[m]> maybe wait for travmurav, he should know better

07:05 <kettenis> aceridus: see https://github.com/openbsd/src/commit/74edc71ccae4051eda11fa3fb27de52f69e7512e

07:06 <kettenis> the acpi stuff uses some weird mapping for some of the gpio pins

07:06 <kettenis> I have some suspicion this happens for wakeup-capable pins

07:09 <jenneron[m]> interesting

07:09 <jenneron[m]> then try 32 instead of 320

07:09 <kettenis> so 320 (0x140) seems to be really pin 32

19:55 <aceridus> jenneron[m]: kettenis: Just tried it with gpio 32: https://dpaste.com/EZATS2DUH Still no keyboard. Anything in particular I can extract from /proc or /sys to figure out why?

20:02 <kettenis> what made you add those "drive-strength" and "bias-pull-up" properties?

20:04 <kettenis> hmm, I guess acpi indeed say "PullUp", so that may indeed be right

20:05 <kettenis> but "drive-strength" doesn't make sense for an input pin I thnk

20:09 <aceridus> kettenis: I am very novice when it comes to understanding DT and how it describes hardware. I have largely been following the lead of folks in here, just doing most of the build iteration and info gathering work. I am learning quite a lot, so there is some hope I will eventually understand how to make correct DT entries on my own :)

20:14 <aceridus> kettenis: I am seeing on dmesg "geni_i2c a84000.i2c: Bus frequency not specified, default to 100kHz." Is that a potential problem? Does the keyboard behind i2c7 need a higher frequency to work correctly?

20:18 <aceridus> All of the gpio pin definitions are inside of pinmux {} type blocks, don't know what that means, maybe my definition needs to be the same way?

20:19 <kettenis> dunno; I don't do Linux

20:23 <aceridus> Still no keyboard with the 'drive-strength' property commented.

20:55 <kettenis> aceridus: does anything about hid-over-i2c show up?

21:24 <hexdump01> aceridus: maybe its not really i2c7 - see https://oftc.irclog.whitequark.org/aarch64-laptops/2022-08-18#31267883 and https://oftc.irclog.whitequark.org/aarch64-laptops/2022-08-19#31270413 (and on from there)

22:39 <jenneron[m]> aceridus: this is right, just checked, acpi i2c7 is &i2c6 node in dts