ChanServ changed the topic of #linux-msm to:
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
Daanct12 has quit [Quit: WeeChat 4.2.2]
ungeskriptet is now known as Guest4474
ungeskriptet has joined #linux-msm
Guest4474 has quit [Ping timeout: 480 seconds]
mripard_ has joined #linux-msm
mripard has quit [Ping timeout: 480 seconds]
mripard has joined #linux-msm
mripard_ has quit [Ping timeout: 480 seconds]
<bryanodonoghue> calebccff how are you stuck
<bryanodonoghue> op6 is sdm845 right ?
<bryanodonoghue> I have an rb3 with the camera mezzanine I could conceivably put onto cdba
<bryanodonoghue> we need to get a) camnoc b) cphy working in camss
<bryanodonoghue> cphy I had a little look and I believe is 99% init sequence
<bryanodonoghue> but also some if/else in the driver
<bryanodonoghue> so if its a cphy you're trying to bring up and you've only done the init seq
<bryanodonoghue> I'd say the gap is in the PHY driver itself lacking the 2-3 if/else we require
<calebccff> bryanodonoghue: sounds about right, this is most of my c-phy bringup (clock rates validated against downstream from dumps I took while streaming video) https://gitlab.com/sdm845-mainline/linux/-/commit/41208a804f60975ea8af9026874d71f2f2b680a1
<bryanodonoghue> op6 must have 2 more sensors ?
<calebccff> bryanodonoghue: i also took register dumps from downstream and confirmed that the CSIPHY registers match
<bryanodonoghue> why not try for the dphy first ?
<bryanodonoghue> csiphy_settle_cnt_calc() will need to be updated for cphy
<bryanodonoghue> I don't believe we can retrieve bits on the wire with the algorithm in that function in cphy mode
<calebccff> i hardcoded the settle count based on downstream values
<bryanodonoghue> setttle time is different
<calebccff> d-phy first is probably the right move
<bryanodonoghue> off the top of my head I don't recall the details but for whatever reason this stands out in my mind
<bryanodonoghue> recommend
pespin has joined #linux-msm
mripard has quit [Remote host closed the connection]
<marc|gonzalez> thanks robher
<marc|gonzalez> thanks vikash
enok has quit [Remote host closed the connection]
enok has joined #linux-msm
telent has quit []
telent has joined #linux-msm
robertfoss has quit [Ping timeout: 480 seconds]
<aka_[m]> lumag: regarding these patches:
<aka_[m]> CTLs on 8953/8996 based on flats appear to not have BITs describing them in INTR2_EN/STATUS/CLEAR
<aka_[m]> which is probably described in errors thrown by dpu core
robertfoss has joined #linux-msm
<Marijn[m]> Oh Luca Weiss that error message explains why I see patches like https://github.com/SoMainline/linux/commit/7ddd74f0095a2882f3517b32fb0c01ff61434628 float on the lists from time to time
<Marijn[m]> I don't exactly remember if we're supposed to check a different interrupt on "older" HW (this was for MSM8998 fwiw)
<Marijn[m]> Whoops I should have linked v2, there's an obvious typo in that patch (it checks if the callback exists, not what it would return): https://lore.kernel.org/linux-arm-msm/20210911163919.47173-2-angelogioacchino.delregno@somainline.org/
<aka_[m]> Marijn: sde code just goes yolo
<Marijn[m]> Hence the || 1 😝
jhovold has quit [Ping timeout: 480 seconds]
<calebccff> I'm trying to use gpio-keys with interrupts-extended and it doesn't seem to work
<calebccff> the "irq_of_parse_and_map()" call returns 0
<calebccff> instead of the IRQ number
<calebccff> I'm trying to model a camera kill switch, so that when enabled it sends KEY_CAMERA_ACCESS_DISABLE, and when disabled it sends KEY_CAMERA_ACCESS_ENABLE: https://p.calebs.dev/909f6a@raw
<calebccff> but i just get "Found button without gpio or irq" in dmesg
pespin has quit []
<z3ntu> calebccff: Last time I checked the core irq code just tries either interrupts + interrupt-parent or interrupts-extended so they should be pretty much the same?
<z3ntu> maybe two keys can't use the same tlmm pin as irq?
<calebccff> z3ntu: i tried disabling the second one but no change, the only way it works is if I add interrupt-parent = <&tlmm>;
<calebccff> also gpio-keys sets IRQF_SHARED so that should be fine
<z3ntu> but there's also nothing bad about using interrupt-parent+interrupts instead of interrupts-extended
<calebccff> z3ntu: well I think the DT folks have a strong preference for interrupts-extended
<konradybcio> I think interrupt-parent makes sense for interrupt providers that are downstream of e.g. gic
<konradybcio> Similar to wakeup-parent
<calebccff> z3ntu: konradybcio: seems to be because I had IRQ_TYPE_EDGE_FALLING, works with rising, im guessing I need compatible pincfg?
<calebccff> i guess there's some weird niche behaviour difference between -extended and using interrupt-parent
<calebccff> hmm so the second entry is failing with "irq: type mismatch, failed to map hwirq-68 for pinctrl@f100000!"
<calebccff> is it really not possible to have devices register handles for falling and rising separately?
<calebccff> I'll just try with GPIO active low/high instead of interrupts
<calebccff> oh right -_- error -EBUSY: failed to get gpio
<calebccff> ARGH why can't this just work
<konradybcio> So do you want to watch the rising edge with one handler and falling with another?
<calebccff> konradybcio: yeah for "CAMERA_ACCESS_ENABLE/DISABLE" heh
<calebccff> i guess what i don't want is to have to try and add new stuff to input-event-codes.h
<calebccff> but im not seeing a good way arond that
<calebccff> these are switches, so using EV_KEY is probably wrong
<calebccff> there's SW_CAMERA_LENS_COVER which I assume achieves the same purpose but it was named based on what it is not what it does so
<calebccff> yay
<calebccff> no SW_MIC_MUTE :(
<konradybcio> There must be one for mic too, there's a supported thinkpad ec mic key
<calebccff> konradybcio: yeah it's EV_KEY_MICUTE
<calebccff> MICMUTE*
<konradybcio> Xiaomi Mi Cute