Danct12 changed the topic of #msm8937-mainline to: Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline
<lanik123[m]> s/qcom/Qcom/, s/on/in/
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #msm8937-mainline
<lanik123[m]> Display is now working on santoni
<barni2000[m]> btw i think we should fork this https://github.com/msm8916-mainline/linux-panel-drivers
<barni2000[m]> and this https://github.com/msm8953-mainline/alsa-ucm-conf or the upstream repo
<jojo_autoboy[m]> why fork?
<barni2000[m]> sound should not be so hard
<barni2000[m]> because our kernel is not in sync with msm8916 completely
<hacker420[m]> eh
<jojo_autoboy[m]> well does that affect the panel drivers at least>
<hacker420[m]> I don't think forking makes much sense
<jojo_autoboy[m]> s/>/?/
<barni2000[m]> and panel configs easier to maintain in this community
<jojo_autoboy[m]> ive used panel drivers generated from the 8916 tool on very much not 8916 devices with 0 issues
<hacker420[m]> except let's also not keep around pointless forks
<barni2000[m]> fork, delete every msm8916 device and add ours
<hacker420[m]> but why
<jojo_autoboy[m]> for panel drivers that doesn't make much sense
<hacker420[m]> what harm would we have in upstreaming the driver
<jojo_autoboy[m]> yeah
<barni2000[m]> because sometime you want to regenerate the panel drivers
<barni2000[m]> and don't want to add panels related to msm8916
<hacker420[m]> then just disable the ones you don't need?
<jojo_autoboy[m]> panel drivers aren't tied to soc
<hacker420[m]> exactly
<barni2000[m]> but there is a script which generate the panel drivers for the every device
<jojo_autoboy[m]> you can take a 8916 panel driver and use it on a non qcom
<hacker420[m]> barni2000[m]: yes and?
<hacker420[m]> it isn't tied to 8916
<barni2000[m]> almost every device has a different panel it related to the devices
<hacker420[m]> I don't see your point tbh
<jojo_autoboy[m]> panel drivers can be shared too
<jojo_autoboy[m]> barni2000[m]: gosh dang it
<M0xCAFEBABE[m]> hacker420[m]: +1, doesn't seem to have any valid reason to make a fork
<hacker420[m]> barni2000[m]: but why
<hacker420[m]> the drivers don't change between SoCs
<barni2000[m]> we don't fork the generator only the configs repo
<barni2000[m]> there are not too much common panel in use
<lanik123[m]> <barni2000[m]> "btw i think we should fork..." <- For what? Add our panels dtb into it and automate generation of panels?
<barni2000[m]> the repo contains every device dt
<barni2000[m]> * the repo contains dt of the devices
<f_> Too much [m] matrix users
<f_> Feels good to be the only one using IRC. -j
<barni2000[m]> lanik123[m]: yes, semi-automate
<hacker420[m]> f_: eh
<hacker420[m]> this isn't some competition
<jojo_autoboy[m]> perhaps we should like discuss this with whoever owns the 8916 repos on if non 8916 devices can be put in it too
<f_> Danct12: Perhaps put that to the topic though?
<hacker420[m]> jojo_autoboy[m]: yeah
<f_> hacker420[m]: I never said it was.
<hacker420[m]> poke minecrell[m]
<jojo_autoboy[m]> i say it should be a nice singular repo for any qcom device
<barni2000[m]> btw for msm8953 we should do some changes in panel-driver generator also but as you feel we could add the devices to the msm8916 repo also but i think it much cleaner keep it separately
<f_> Danct12: Something like "| Bridged to #msm8937-mainline:kde.org" on IRC and "| Bridged to #msm8937-mainline on irc.oftc.net" should do.
<hacker420[m]> well the ideal solution would be to upstream them all
<f_> ^ hacker420[m]
<jojo_autoboy[m]> well yeah
<barni2000[m]> hacker420[m]: not a chance for them
<f_[mtrx]> Thanks
<hacker420[m]> barni2000[m]: so what
<barni2000[m]> i wish for a generalized driver what can use some config
<hacker420[m]> will we just keep these rotting in a fork?
<hacker420[m]> this isn't sustainable long term
<f_[mtrx]> Wait
<barni2000[m]> the panel driver generator is a submodule and maintained by msm8916 so not a problem
<jojo_autoboy[m]> it's still kinda a gray area on if generated drivers can enter mainline
<hacker420[m]> jojo_autoboy[m]: yes
<hacker420[m]> this question would be better suited for mainline kernel maintainers
<barni2000[m]> they cannot be upstreamed because every driver needs a maintainer
<f_[mtrx]> hacker420: "Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Bridged to #msm8947-mainline on irc.oftc.net"
<barni2000[m]> you don't want to maintain 100 panel drivers
<hacker420[m]> yeah felt something was off
<f_[mtrx]> Alright, thanks :)
<hacker420[m]> np
<hacker420[m]> barni2000[m]: ofc
<f_[mtrx]> Just have to wait for Danct12 to do the same on IRC side.
<hacker420[m]> but you don't want these sitting in a fork either
<barni2000[m]> every community do the same
<jojo_autoboy[m]> or at least have one big singular fork instead of a bunch of soc specific ones
<hacker420[m]> ok but does it mean you have to replicate what they do?
<hacker420[m]> exactly
<hacker420[m]> have a SoC specific one
<hacker420[m]> not 2 billion ones for every SoC
<f_[mtrx]> hacker420 wish to also have an online chatlog link too?
<barni2000[m]> these stuff is not hard to maintain
<hacker420[m]> that turns into downstream mess really quick
<f_> Topic (set by Danct12 on November 12 2023 at 16:21:04): Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline
<barni2000[m]> msm8953 has about 200-300 not upstreamed commit many of them cannot be upstreamed
<hacker420[m]> barni2000[m]: yes
<hacker420[m]> there are some things you can't upstream
<barni2000[m]> that is the sad reality
<hacker420[m]> doesn't mean we shouldn't strive to upstream what we can
<f_[mtrx]> To be consistent with IRC: "Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline | Bridged to #msm8937-mainline on irc.oftc.net"
<f_[mtrx]> Anyway, cool!
<barni2000[m]> we should upstream everything what we can and worth it
<barni2000[m]> panel drivers are not worth to upstream (yet)
<f_[mtrx]> Cool!
<f_> ^ Danct12 Danct12[m]
<hacker420[m]> barni2000[m]: then at least let's have one panel driver fork
<hacker420[m]> not one for every SoC family
<barni2000[m]> as is said almost every soc forking the config repo
<barni2000[m]> s/is/I/
<hacker420[m]> well yes we know what IS happening
<hacker420[m]> question is why
<barni2000[m]> because they store the dts for the panels
<jojo_autoboy[m]> instead of following in their steps perhaps we should like fix this issue
<hacker420[m]> jojo_autoboy[m]: yes
<jojo_autoboy[m]> tbh already the panel driver generator being under the 8916 org is a bit meh
<hacker420[m]> the way it's done now just seems like a big mes
<barni2000[m]> other approach we should merger everything with msm8916-mainline
<hacker420[m]> s/mes/mess/
<barni2000[m]> kernel also
<hacker420[m]> thing is
<hacker420[m]> I feel there likely are too many quirks to do that cleanly
<jojo_autoboy[m]> i mean it worked with the 8939 but not sure if the 8937 is too different to be under the same thing
<barni2000[m]> these two repo worth to fork in our scope i think (panel-configs and ucm)
<hacker420[m]> Wait
<hacker420[m]> why UCM though
<barni2000[m]> lk2nd stuff could be upstreamed when the new is released
<hacker420[m]> they don't store blobs
<barni2000[m]> hacker420[m]: for the device specific configuration
<hacker420[m]> at least there was some point to keeping things separate when blobs are involved
<hacker420[m]> barni2000[m]: ok but then why keep every device specific config in specific SoC repos
<barni2000[m]> every device should have own config with shared HiFi.confs
<barni2000[m]> hacker420[m]: easier to maintain the ucm configurations together
<barni2000[m]> for msm8916 and msm8953 there is a soc package what is handles shared configs and ucm
<hacker420[m]> yes there I can understand separation
<barni2000[m]> btw ucm is related to the kernel
<barni2000[m]> in the past msm8916 do some downstream changes what needed some ucm changes but msm8953 kernel doesn't contained those changes and jack control was broken
<barni2000[m]> so ucm should be in sync whit our kernel
<hacker420[m]> lanik123: was panel tested on 8937?
<hacker420[m]> guess 8940 is close enough?
<hacker420[m]> should maybe test on cedric tomorror
<hacker420[m]> s/tomorror/tomorrow/
<barni2000[m]> difference is the modem and it uses higher clock afaik
<lanik123[m]> hacker420[m]: If 8940 works, then 8937 works too
<hacker420[m]> good
<jojo_autoboy[m]> i should try on my land
<lanik123[m]> If someone need it... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/OqZbPQuGNrptCJLjAuAzPNiZ>)
<lanik123[m]> lanik123[m]: > <@lanik123:matrix.org> If someone need it... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/SmoSTgajWdsJrovbaAffGDyn>)
<jojo_autoboy[m]> oh gosh dang it it was already one
<jojo_autoboy[m]> s/one/done/
<hacker420[m]> lanik123[m]: so that land dts has a working panel?
<jojo_autoboy[m]> oh wait that's the old kernel
<jojo_autoboy[m]> i guess these dts should be upstreamed
<lanik123[m]> hacker420[m]: Depends on what panel you have
<hacker420[m]> well ofc it won't work with land's panel
<jojo_autoboy[m]> * be upstreamed to our fork
<hacker420[m]> I have a tianma panel
<jojo_autoboy[m]> hacker420[m]: what?
<jojo_autoboy[m]> why?
<barni2000[m]> hacker420[m]: lk2nd
<hacker420[m]> I meant on cedric
<jojo_autoboy[m]> ah
<hacker420[m]> barni2000[m]: hm?
<barni2000[m]> hacker420[m]: nvm
<M0xCAFEBABE[m]> lanik123[m]: > <@lanik123:matrix.org> If someone need it... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/iUyksvchzMnfbdMTOPdnCEoM>)
<barni2000[m]> i will check land with my dt
<M0xCAFEBABE[m]> * btw, for prada it's better to redo dts with my new downstream dts as reference, it's more correct, or lemme do it when I have time
<jojo_autoboy[m]> from what i can see land is very close to santoni (downstream calls it landtoni lol)
<lanik123[m]> hacker420[m]: lol, generate panel driver through panel generator with -r vsn -r vsp params
<lanik123[m]> lanik123[m]: It's not difficult
<jojo_autoboy[m]> there's support for the vsn/vsp regs now?
<M0xCAFEBABE[m]> jojo_autoboy[m]: it's the name which I gave to land&santoni back in 2021 XD, now I don't use it anymore, it's cringe
<hacker420[m]> lanik123[m]: yeah I know
<jojo_autoboy[m]> M0xCAFEBABE[m]: oh lmao
<M0xCAFEBABE[m]> M0xCAFEBABE[m]: because I used to unify those 2 devices
<M0xCAFEBABE[m]> * 2 devices (now all 7 devices)
<lanik123[m]> jojo_autoboy[m]: It always been
<hacker420[m]> how do I check if I need that, downstream?
<hacker420[m]> ```
<hacker420[m]> * &dsi_phy0 {
<hacker420[m]> };
<hacker420[m]> qcom,dsi-phy-regulator-ldo-mode;
<jojo_autoboy[m]> M0xCAFEBABE[m]: ah so all of them are almost the same?
<jojo_autoboy[m]> such a xiaomi move
<M0xCAFEBABE[m]> jojo_autoboy[m]: * basically same, because they're designed by the same ODM
<M0xCAFEBABE[m]> s/*//
<jojo_autoboy[m]> reminds me of the miatoll situation
<jojo_autoboy[m]> difference is they are literally the same exact phone with like 5 diffrent names
<jojo_autoboy[m]> s/diffrent/different/
<hacker420[m]> wait where is that defined? `&mdss_dsi_active`
<lanik123[m]> hacker420[m]: If I'm not mistaken, all 8917/8937/8940 devices use this option
<lanik123[m]> lanik123[m]: It's specefied it mdss dts
<hacker420[m]> lanik123[m]: then why doesn't prada have it?
<lanik123[m]> s/it/in/
<M0xCAFEBABE[m]> jojo_autoboy[m]: wait, you were referring to 7 devices right? 3 different ODMs then
<lanik123[m]> hacker420[m]: Good question)))))))))
<M0xCAFEBABE[m]> M0xCAFEBABE[m]: ugg/ugglite: Longcheer, prada: FIH, rest: Wingtech
<jojo_autoboy[m]> oh
<M0xCAFEBABE[m]> M0xCAFEBABE[m]: one more thing, apparently devices from the same ODM shares the same BSP, only except for land
<barni2000[m]> yes but riva and rolex using different fg and charging ic, land santoni using pmi8950-charger
<M0xCAFEBABE[m]> * more thing, in mi8937 devices, apparently devices
<jojo_autoboy[m]> fun
<barni2000[m]> land and santoni are easy to support other will have issues
<barni2000[m]> s/other/others/
<jojo_autoboy[m]> oh nvm
<jojo_autoboy[m]> nice
<hacker420[m]> ah
<barni2000[m]> btw riva is wingtech ugglite is longcheer but they are very similar
<M0xCAFEBABE[m]> barni2000[m]: well, I'd rather say ugg&ugglite are similar
<barni2000[m]> M0xCAFEBABE[m]: yes i know
<barni2000[m]> i have both of them
<M0xCAFEBABE[m]> the only similar part between ugglite&riva is the SoC and charging chips (charging chips are the same for ugg too)
<barni2000[m]> M0xCAFEBABE[m]: and led
<M0xCAFEBABE[m]> barni2000[m]: aw2013 is veryyyyyy common on ximi msm8937/53 devices
<lanik123[m]> lanik123[m]: I do not recommend specify driver for the wled and specifying regulators in the DTS now. This causes mdp delayed probe
<lanik123[m]> lanik123[m]: This is how node for panel should look like
<barni2000[m]> btw you can try dpu
<lanik123[m]> barni2000[m]: No no no no
<lanik123[m]> lanik123[m]: Forget about it
<lanik123[m]> It cursed
<barni2000[m]> mdp5 is cursed
<barni2000[m]> dpu is maintained
<hacker420[m]> lanik123[m]: alright
<barni2000[m]> but there is no upstream support yet for msm8917/msm8937
<lanik123[m]> barni2000[m]: mdp4 is cursed, mdp5 beautiful compared to him
<hacker420[m]> lanik123[m]: you know what I feel will be more cursed
<hacker420[m]> the sensorhub shit lenovorola used
<hacker420[m]> wonder if potter has the same thing
<barni2000[m]> lanik123[m]: i have tested dpu on msm8953 it works much better for me
<barni2000[m]> it solves many display issue
<barni2000[m]> * it has solved many display issue
<lanik123[m]> barni2000[m]: Hmmm, If dpu supports 8953 then it's not a big problem to add 8917 and 8937
<barni2000[m]> linaro guys are working on it
<lanik123[m]> barni2000[m]: Wow
<lanik123[m]> Nice
<barni2000[m]> but it has some dependency on other patchsets and it not upstreamd yet because of cmd panels
<hacker420[m]> lanik123[m]: it already has 8937
<hacker420[m]> very nice
<barni2000[m]> yes, i think we could help with the testing if they resending the patches in the future
<hacker420[m]> that looks right?
<hacker420[m]> btw
<hacker420[m]> what do I put in the panel compatibles
<hacker420[m]> leave them as is?
<hacker420[m]> or just remember to put that in dts
<hacker420[m]> lanik123[m]: so put this in
<barni2000[m]> yes
<lanik123[m]> Yep
<hacker420[m]> <lanik123[m]> "It's specefied it mdss dts..." <- I don't have a mdss dts in downstream
<lanik123[m]> Lol what
<lanik123[m]> hacker420[m]: So it's not need for you
<barni2000[m]> at msm8953 we add device name also as a prefix for the generated panels
<barni2000[m]> [boe_hx8394f_720p_video]="xiaomi,onclite-hx8394f" second part will be the compatible btw
<barni2000[m]> i wonder is montana using the same panel what cedric?
<barni2000[m]> #include "dsi-panel-mot-tianma-521-1080p-video.dtsi"
<barni2000[m]> #include "dsi-panel-mot-inx-521-1080p-video.dtsi"
<barni2000[m]> it seems not
<barni2000[m]> #include "dsi-panel-mot-tianma-497-1080p-video.dtsi"
<barni2000[m]> #include "dsi-panel-mot-inx-497-1080p-video.dtsi"
<hacker420[m]> Error: ../arch/arm64/boot/dts/qcom/msm8937-motorola-cedric.dts:27.2-17 syntax error
<hacker420[m]> FATAL ERROR: Unable to parse input tree
<hacker420[m]> fuck I hate how unhelpful the dts parser is when you have a syntax error
<hacker420[m]> OT: amazing thing to queue up on yt right as I started messing with the DTS
<barni2000[m]> <hacker420[m]> "Error: ../arch/arm64/boot/dts/..." <- > <@hacker420:kde.org> ```... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/tzXNhpnPwhbYIQQRVPjeVOHR>)
<barni2000[m]> in the line 27
<barni2000[m]> or before
<hacker420[m]> hm let me make it more similar to land's dts formatting
<hacker420[m]> what
<hacker420[m]> Ah wait
<hacker420[m]> put in .c instead of .o in makefile
<barni2000[m]> the panel driver generator makes a commit if you execute from the kernel repo root
<barni2000[m]> and it modifies everything afaik