ChanServ changed the topic of #linux-msm to:
sdfgsdfg has joined #linux-msm
<abhinav__> Marijn[m] Happy new year !
sdfgsdfg has quit []
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
sdfgsdfg has joined #linux-msm
sdfgsdfg has quit []
sdfgsdfg has joined #linux-msm
sdfgsdfg has quit []
<malvi[m]1> Happy new Year!
cxl000 has quit [Quit: Leaving]
sdfgsdfg has joined #linux-msm
sdfgsdfg has quit []
cxl000 has joined #linux-msm
sdfgsdfg has joined #linux-msm
sdfgsdfg has quit []
<aka_[m]> out of wonder, will 6.2-rc2 get out today?
<aka_[m]> i understand for new "next" we still have one more week
<flamingradian[m]> "So it's Christmas Day here, but it's also Sunday afternoon two weeks after the 6.2 merge window opened. So holidays or not, the kernel development show must go on." - Linux 6.2-rc1 announcement
<mal> Rayyan: https://pastebin.com/iaXALSeE smbb backtrace from my device
<aka_[m]> devm_power_supply_register fails?
<aka_[m]> this helper appears to throw error
<aka_[m]> mal: not missing some prop?
frytaped is now known as Guest943
Guest943 is now known as go4godvin
<mal> aka_[m]: that is not listed as required
<mal> could be a bug of course
<mal> aka_[m]: based on qcom_smbb.c that usb-otg-in-supply is used after the failing call so it shouldn't affect it https://github.com/torvalds/linux/blob/master/drivers/power/supply/qcom_smbb.c#L956
flto has quit [Read error: Connection reset by peer]
flto has joined #linux-msm
<JIaxyga[m]> Marijn: Okay, I have a little more time. What do I need to test?
<JIaxyga[m]> I will probably need to add a regulator for panel
<Marijn[m]> JIaxyga: is this in reply to a specific message, or just in general regarding DSC?
<Marijn[m]> You've reached me at exactly the wrong moment; one of the reasons I sent INTF TE on new years eve is because I won't be available for some time...
sdfgsdfg has joined #linux-msm
<Marijn[m]> In any case, if you want to test anything, take the latest -next and apply my "DSC electric boogaloo" and INTF TE patch series on top. Make sure your DPU hw catalog utilizes this change (unless using an SoC that's already merged; you're on sm8150 right?) and that your panel driver sets the right values for DSC; take specific care for the `<<4` on bits_per_pixel and actually sending the PPS to the panel via DCS
<JIaxyga[m]> Marijn[m]: Yes, I'm talking about dsc. But since you're busy, we'll save it for later. In any case, I do not think that my tests will change anything
<JIaxyga[m]> Marijn[m]: sm7150 + video mode panel
<Marijn[m]> JIaxyga: It'd be good to know the state of DPU + DSC on newer SoCs on video panels regardless, but only on recent -next with my series so that we're using the same codebase. I had hoped to compile a dpu-specific branch with all these patches (i.e. for konradybcio to rebase on, with many Sony devices relying on these) but no promise that I can get that done before "disappearing"
<Marijn[m]> JIaxyga: ack, sm7150. I submitted a bunch of patches to you for that. Those INTF TE changes won't have any effect on video mode, and I think you confirmed the "DSC electric boogaloo" series didn't fix anything? Fwiw my PR (and your `v6.1` and `dsc_test` branches) don't include that full series so it'd be great if you can apply those locally and retest (you may have to drop some duplicate commits first)
sdfgsdfg has quit []
<aka_[m]> <Marijn[m]> "You've reached me at exactly the..." <- nowhere around kernel development, or just not there
<Marijn[m]> aka_: msm8976 won't be forgotten about if that's what you mean ;)
<aka_[m]> thats nice.
<aka_[m]> im going to send new device tree once next land
<Marijn[m]> aka_: that'd be lovely, having more devices using the tree even if just on minimal feature support
<Marijn[m]> (On that note, JIaxyga where is sm7150 upstream?)
<JIaxyga[m]> Marijn[m]: I'm thinking of sending the first patches this week
<aka_[m]> and maybe you can look into some small patch too.
<aka_[m]> As you noticed i don't really understand how stuff work even if i happen to be able to "modify" it so pretty much why i cannot explain what and how.
<aka_[m]> i might be able to send some early RFC for CPUFreq for 8976 would be nice if you can test on Loire
<Marijn[m]> aka_: I'll start sending display when I return. It'll be a bit of both; I can occasionally be in this channel to reply while having minimal (mostly inconvenient) kernel source access, but cannot develop/test/send anything next week. The week after I can, but there's likely zero time for it. After that we'll see ;)
<aka_[m]> JIaxyga[m]: uh at this point better wait for next
<aka_[m]> now its quite bothersome to find what is merged already and where
<Marijn[m]> aka_[m]: Don't wait, just send whenever you have something useful. We're not tied to Linux releases, community review happens all the time and maintainers pick it up as they go
<Marijn[m]> > <@aka_:matrix.org> and maybe you can look into some small patch too.
<Marijn[m]> Is this referring to my comment on your pinctrl patch?
<Marijn[m]> > As you noticed i don't really understand how stuff work even if i happen to be able to "modify" it so pretty much why i cannot explain what and how.
<aka_[m]> yea
<Marijn[m]> aka_[m]: Doesn't kholk have this all ready to go on some branch already?
<aka_[m]> i don't really understand structures
<aka_[m]> Marijn[m]: haven't seen, not like he push anything
<aka_[m]> and last time he said he had issues with it using standard stuff
<Marijn[m]> aka_: that's expected, these macros hide the fact that global identifiers are being referenced :)
<aka_[m]> this exact issue with pinctrl cost me one year of not working wifi
<aka_[m]> no really any proper error code
<Marijn[m]> At this point I'm just curious if the pin was even settable, since the pingroups that are part of the function completely mismatch the function(s) that are part of the pin
<Marijn[m]> I don't know why pinctrl holds duplicate info in this way nor spits out an error for this conflict...
<aka_[m]> there are some small patches which i need to rephrase commit msgs:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/dwvdaKyRVxAZsiaijWzxULFY>)
<aka_[m]> small patches, for rephrase of commit msgs but probably valid
<Marijn[m]> aka_: you have a bunch of colorful branch names :)
<aka_[m]> im not developer so i feel entilted to being unorganized xD
<aka_[m]> need to test if rpmpd max power state tho, it might be broken
<aka_[m]> s/if//
<Marijn[m]> Well post the patches to the list and wait for review :) - it's hard for me to tell
<aka_[m]> well thats why i want to always ask before so i won't end in situation
<aka_[m]> "wrong commit msg, you do something else instead"
<aka_[m]> again im not developer, yet i enjoy when i get something to work >_>
<Marijn[m]> aka_: you just said you still have to rephrase the commit messages, so then it makes no sense for me to review those messages in the current state?
<aka_[m]> not really
<aka_[m]> once they are ready but not on list i hope
<Marijn[m]> Yes that would be useful. But I may not be available by that time - though again there's no hurry to get things on the list, upstreaming SoCs is supposed to be a fun and rewarding hobby project, not a time-pressured thing :)
<aka_[m]> next week(so starting from tomorrow) i will just spend on cleaning nvt-ts from msm-5.10 for non-upstream bringup
<aka_[m]> i know Angelo had something but i have SPI one
<Marijn[m]> Anyway, for patch 2 I think you're right, I had to provide the xo_board fixed clock to rpmcc as well on different boards; no idea why it isn't causing an issue here
<aka_[m]> its quite big thing to strip qcom secure touch and remove duplicated code for spi/i2c withing single driver guarded behine IF
<aka_[m]> Marijn[m]: it was for me
<aka_[m]> everything was black
<aka_[m]> same with 662 but Konrad send fix for that
<Marijn[m]> Yeah I mean it should have caused issues, the same that I saw on other platforms (iirc rpmcc not even probing because of this being a mandatory clock?)
<aka_[m]> with some touches working i could start remoteprocs and IPA on 662 and leave worst part so GPU to Konrad
<Marijn[m]> Oh right, konradybcio asked me to test GPU on 6125 as well...
<Marijn[m]> But we're also in branch-mess right now, which is hopefully mostly resolved when -next is updated where most of the patches landed...
<aka_[m]> i have it easy as he has 6115 tab too
<Marijn[m]> Yep, same here - except he's deferring all things DPU to me :/
<aka_[m]> there is also 6225 with A610
<aka_[m]> noone has it here i think
<Marijn[m]> Nope, none here - haven't even heard of it yet
<aka_[m]> its quite popular, Snapdragon 680
<aka_[m]> GKI loved target
<Marijn[m]> But to be honest I'm not actively looking for SoCs anyway, already have a hard time remembering what I have here 😅
<aka_[m]> i stopped understanding qcom lineup after 855
<Marijn[m]> Hehe, yes
<aka_[m]> and today i noticed 855 is EOL already
<aka_[m]> quite funny how fast they kill so strong stuff
<aka_[m]> by EOL i mean devices with it
<Marijn[m]> It's even more of a mess when most hardware blocks probably have an internal revision/version, but we don't know that so every driver uses the SoC name in compatibles (and now we're using a "fallback compatible" with a random SoC name that just happened to be first added to the driver...)
<Marijn[m]> aka_: yes, downstream is messy like that :)
<Marijn[m]> That's why we're upstreaming these things - make them live on
<aka_[m]> i was flexing around PLL code last time and noticed codenames for these "IP" are just lie
<Marijn[m]> Car names :)
<aka_[m]> SR2PLL have very close design to HF one
<aka_[m]> not even mentioning code is missleading
<aka_[m]> SR_PLLs configure says it writes to config_reg while from PLL perspective its user_reg
<aka_[m]> config_reg is bit later
<aka_[m]> and msm8916 code skip configuring it because it happens reset value is used
<aka_[m]> so we pretend sr2pll is different than srpll
<aka_[m]> there is chance older SoC define wrong config/user_reg but its not breaking because nothing is configured, however no flats i cannot confirm it.
<Marijn[m]> Sounds intriguing, nothing I have any experience with though
<aka_[m]> Marijn: out of wonder, have you tested ninges lately?
<aka_[m]> It appears newer mesa 22.x have some ugly bug where adreno hangs, i noticed it on a510 and Jami on a540(?8998)