06:10 <Lightsword> anyone know how one might go about determining the correct irq and reset gpio's for configuring a touchscreen in a device tree?

08:38 <jn> Lightsword: if available, i'd look at the schematics for the board in question

08:39 <Lightsword> jn, yeah...that's kind of the problem, vendor does't provide schematics, it's similar to one that has schematics but this particular touchscreen is a different model from the one with schematics

08:40 <jn> which are unfortunately often unavailable for proprietary electronics, in which case, you'd have to look at existing code which uses the IRQ/reset pins (software reverse-engineering), or trace the board (hardware reverse-engineering)

08:43 <Lightsword> jn, yeah so I decompiled the vendor device tree...however the irq's/gpio's configured there for the touchscreen don't seem to be configured entirely correctly there either as the vendor kernel throws a bunch of irq/rst gpio related warnings on startup(although it does eventually seem to start up), in my build it sometimes sorta works but seems to glitch

08:43 <jn> hmm

08:49 <Lightsword> is it possible to apply a pinctrl configuration only when the touchscreen i2c register is present?

08:50 <jn> i don't think so

08:52 <Lightsword> one issue I think is that the device has multiple touchscreen variants that need to by dynamically detected based on the i2c register addresses, currently there's multiple touchscreens configured in the i2c node and I'm thinking they may conflict somehow

08:53 <jn> ah

08:53 <jn> i've seen this kind of situation before, but i don't know if there's a standard solution for it yet

08:54 <Lightsword> jn, yeah like the vendor device tree has 3 different touchscreen drivers configured and I think only one is ever actually present

08:55 <Lightsword> jn, yeah so the cleaned up decompiled vendor device tree looks like this https://gist.github.com/jameshilliard/eada06e2124972b48d20175d997ae43c

08:56 <Lightsword> ctw6120_tsc@38 is the normal touchscreen controller on the board their custom board is derived from which seems to work ok, tsc@0x24 is the one I'm trying to use and I haven't seen the hardware using tsc@0x48

19:35 <ukleinek> mmind00: I'll mark 20230731103518.2906147-2-jagan@edgeble.ai as handled-elsewhere in the pwm patchwork.

19:37 <mmind00> ukleinek: sounds great ... and I've seen your mail reply now too :-D ... I'll pick this patch together with the rest then

19:57 <broonie> Lightsword: dianders has a patch on the list for exactly that scenario at the minute

19:58 <Lightsword> broonie, oh, cool, have a link to that? I'll try and test it out

19:59 <broonie> Lightsword: not off hand sorry and I’m literally on a plane with in flight WiFi. Should be a very recent post on the DT list I think?

20:02 <javierm> Lightsword: I think is https://patchwork.kernel.org/project/linux-input/patch/20230921102420.RFC.1.I9dddd99ccdca175e3ceb1b9fa1827df0928c5101@changeid/

20:10 <broonie> That’s it yes

20:14 <Lightsword> oh, neat, that looks to be what I'm looking for

20:42 <ukleinek> mmind00: 👍