<calebccff>
lumag: what's the state of DSC on sm8250? i see some Xiaomi phone apparently has it working... should it just work (maybe with a few patches i saw in someone's branch)
<lumag>
calebccff, it should work in the 2:1:1 mode. No dual/bonded DSI though.
<calebccff>
ok cool, pretty sure this device is quite normal, it's just 1080p 120hz
<JIaxyga[m]>
<calebccff> "lumag: what's the state of DSC..." <- You need a hack for the 1.1.1 topology, if your panel is like that. And patches for video mode, if your panel is in video mode. Otherwise, no patches are required
<calebccff>
Jiaxyga: how would one figure out the topology?
<JIaxyga[m]>
JIaxyga[m]: like that: qcom,display-topology = <1 1 1>;
<JIaxyga[m]>
calebccff: wow
<calebccff>
what? XD
<lumag>
JIaxyga[m], sm8250 should be able to use 2:1:1, it has enough encoders. I think you need 1:1:1 only if for sm6350, sm4350, sm6375, and other poor devices with just 1 DSC encoder
<JIaxyga[m]>
Dual topology? Try without hacks first
<calebccff>
im working on the OnePlus 8T, I got U-Boot up and running and I plan to get it into postmarketOS using EFI booting
<JIaxyga[m]>
and Molly Sophia maybe
<JIaxyga[m]>
afaik
<calebccff>
but not sure what to do about maintaining the kernel
<ungeskriptet>
calebccff: Ouhh, nice. I should try getting U-Boot to run on my tablet sometime
<ungeskriptet>
I can add you to the org if you want, but I'll have to ask Jianhua first
<calebccff>
ungeskriptet: definitely! if it's sm8250 you should already get things working just by booting my branch with your DTS. currently missing clock configuration for the primary usb controller so gadget modes only work if you boot via "fastboot boot"
<calebccff>
sure, i mean i already maintain the sdm845 kernel i would also be open to just adding it (and the other sm8250 devices) if folks are willing to help with maintaining
* lumag
thinks it is a good idea, to keep all upstreaming/mainline projects under the same hood
<ungeskriptet>
calebccff: I don't quite understand. What do you mean by "adding it"?
<ungeskriptet>
lumag: I try to upstream as soon as I get working and non-hacky code :D
<lumag>
ungeskriptet, that's great!
<calebccff>
i mean which kernel package the device would use
<calebccff>
there's a lot of duplicated effort with packaging kernel in pmOS, everyone is maintaining a handful of patches on top of mainline and having to rebase and test and update the packages, if we have less kernel packages then that work gets easier
<ungeskriptet>
Ah, now I get it. Yeah, having one kernel for multiple SoCs does make sense
jhovold has quit [Quit: WeeChat 4.1.2]
<aka_[m]>
Luca Weiss: have you had any patches related to pmi632 lets say usb-c/vbus whatever?
<aka_[m]>
now i scroll around patchwork and see one for pm6150 and wonder if there is something like this on pmi632
<calebccff>
aka_: lumag worked on that i think
<Adrian[m]1>
aka_[m]: yes there is one
<aka_[m]>
i guess i would have a use for it on sm6115
<aka_[m]>
now i wish Sir Armstrong would get some qrd/mtp with nvt spi so i would have driver upstreamed
<lumag>
aka_[m], ?
<lumag>
what is nvt?
<aka_[m]>
novatek
<aka_[m]>
Angelo had I2C driver on lists
<aka_[m]>
no spi one
<aka_[m]>
Spi is annoying because its kinda big and there is stuff like firmware loading/single chip doing display/touch which on downstream is handled via notifier so msm_drm emit it when display does unblank then firmware loading kicks in
<aka_[m]>
last time i tried to clean driver it always rebooted somewhere on init_delayed_work
<aka_[m]>
also bad thing vendors tends to modify firmware so you need often per-vendor hacks