07:22 <steev> qzed: it compiles - i still haven't gotten around to reinstalling linux on it, hopefully this weekend sometime

10:11 <macc24> is it me or did display on lazor broke on 5.19-rcsomething

15:03 <qzed> bamse: what specifically is required to "properly" handle the combined pcie1 pcie2 4-lane thing?

15:03 <qzed> just set num-lanes to 4 and make sure both pcieN_phys are properly turned on/off?

15:04 <qzed> or do they need some special/different configuration to work together?

15:06 <qzed> also is not setting is_dual_lane_phy=true for the sc8180x pcie phys on purpose? registers seem to be specd for dual-lane in the DT

15:06 <qzed> (seems to work either way for me)

15:41 <robclark> macc24: you need https://gitlab.freedesktop.org/robclark/msm/-/commit/5883a83a910994d71a6707a3fadf47808d1c7d28

15:41 <robclark> not sure if bamse picked that up yet for -fixes pull req

15:41 <macc24> hmm i'll check

16:10 <macc24> robclark: hey can you comment 'Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com' on that for me? i'm not subscribed to that list

16:30 <robclark> macc24: you can ask bamse.. or follow the reply instructions at https://lore.kernel.org/lkml/20220617111021.v6.6.I423a007e8c4451bd1d091fcb65d035e5dcfc9a9d@changeid/

16:32 <macc24> hmmmmmm ok

19:32 <bamse> qzed: there's a register which defines if the phys work separately or in tandem...in tandem the initialization sequence needs to initialize both phys, in a slightly different way from when they are separate

19:33 <qzed> bamse: okay, thanks! has there been any work on this that I could have a look at?

19:37 <bamse> jhovold has been spending some time on it, not sure if he has release anything yet though

19:39 <qzed> thanks! I'll have a look around

19:39 <qzed> I'm mostly concerned about it not retaining config from suspend, as at the moment it seems it keeps that from UEFI

19:40 <qzed> at least it does work somehow...

19:40 <qzed> alternatively I guess I could mabye set the controller into 2-lane mode and work with a single phy

19:40 <qzed> that does seem to work as well

19:41 <qzed> and with that change in the DT, lspci also reports it's actually x2, so that could get around the second phy

21:21 <steev> qzed: going through the install now, will hopefully be able to test that stuff later today

21:21 <qzed> neat, thanks!

21:22 <steev> https://github.com/steev/linux/commit/be302f8bc09ef226687e5eed2acc65c21693ad8c with your suggested mods

21:23 <qzed> looks like that should do the trick

21:27 <steev> i'm probably gonna need to grab the mbns manually again to get things up and going but once i get it on the network, i'll be giving that kernel a test

22:23 <steev> qzed: so, how do i test?

22:24 <steev> it boots here

22:24 <qzed> not sure, lsusb and check if there are some new devices?

22:24 <qzed> it's some internal thing on the flex, right?

22:24 <qzed> bamse mentioned something about webcams via usb, so maybe those could show up

22:31 <steev> hm

22:31 <steev> i need to poke more, i broke something, rmtfs isn't starting here

22:51 <steev> blergh

22:52 <steev> remote proc is being probe deferred because supplier c300000.power-controller not ready

23:11 <steev> well the good news is, it's not your patches

23:12 <qzed> yeah, that would have been weird... unfortunately I have no clue what the problem could be

23:13 <qzed> there's some issue with dispcc timing out on defered probe, for which bamse has patches

23:13 <qzed> but for the power-controller I have no clue

23:15 <steev> i thought that was the postpone clk_set_rate until the pll is up

23:17 <steev> then again, i haven't tested the flex5g in a while - and looking at the difference between my config and bamse' i don't see anything that would be causing it either

23:18 <qzed> ah that might be possible, I'm still carrying some older patches... I need to update and compare stuff with bameses sc8180x-v5.19-rc1 branch

23:18 <steev> i have the patches from there :/

23:19 <qzed> my current stuff is at https://github.com/linux-surface/kernel/tree/spx/v5.19-rc3

23:19 <qzed> seems like the "disable defered probe timeout for now" got replaced

23:23 <steev> it seems like i'm missing those 7 commits you have after the surface power patches

23:24 <qzed> I'm not really sure what of them is even needed...

23:24 <qzed> for example the UCSI/PAN thing... I don't think that's even referenced in any DT

23:26 <steev> isn't that the stuff bamse is using to do his 2x4K displays?

23:28 <qzed> ucsi is something with USB-C, I think related to HPD signalling for the extenal display ports

23:28 <qzed> so could be

23:29 <qzed> or maybe not hpd, but port orientation, connection, stuff like that

23:35 <steev> well i pulled those 7 in... probably should have done them less at once, but meh

23:39 <steev> the weird part is

23:40 <steev> i dont' actually see anything complaining

23:42 <qzed> maybe something config related?

23:42 <steev> https://paste.debian.net/1245213

23:42 <steev> maybe, but like, the only differences between bamse' 5.19 rc1 config and my 5.19 rc3 config is that he doesn't have the inline encryption stuff enabled

23:43 <qzed> hmm, weird

23:43 <steev> https://paste.debian.net/1245214/

23:44 <steev> the stuff i have enabled are the -, i should have flipped the diff around, but meh

23:45 <qzed> I have a fragment for the spx which also has all the base qualcomm stuff for the sc8180x

23:45 <qzed> https://github.com/qzed/aarch64-kernel-configs/blob/main/fragments/spx.config

23:46 <qzed> I essentially use that with scripts/kconfig/merge_config.sh and a base config from Arch

23:47 <qzed> but might be missing some flex specifics, and I'm also not sure whether the quirks at the top apply to the flex as well

23:47 <steev> mine is essentially, the defconfig

23:47 <steev> just with inline encryption enabled

23:47 <steev> because i use that on the c630

23:47 <steev> [ 1.223621] ufshcd-qcom 1d84000.ufshc: Found QC Inline Crypto Engine (ICE) v3.1.75

23:48 <qzed> I only made that fragment because I eventually want to try and ship some distro-like kernels via github, once we have a bit more stability

23:48 <qzed> the idea is that that contains the minimal(-ish) set of options to make things work

23:49 <steev> makes sense

23:49 <steev> "we" (really shawn) have the distro_defconfig in the aarch64-laptops and i've carried it over as well, occasionally doing a make savedefconfig and copying it into place and committing

23:50 <steev> but that's more to do with what debian expects to be around for its installer

23:55 <steev> qzed: interesting - you have the DISPCC_8250=m something about the display, but here i have it =y

23:55 <qzed> yeah, I think that's a "specialty" of the spx...

23:56 <steev> could be

23:56 <steev> i remember there being *something* required

23:57 <steev> that isn't 8180x, and i think it might hav ebeen that, on the flex

23:58 <qzed> on the SPX there's some hand-off going on with who drives the panel and backlight, essentially the EC drives that during boot until you eventually pull the SoC pin for the backlight up or something... and I'm not sure if there's some interference or why I had to build that as module...

23:59 <qzed> could also be something completely different