18:58 <aka_[m]> Marijn: have you noticed minecrell[m] reply about 28nm phy?

19:16 <Marijn[m]> aka_: no I don't have email, how am I supposed to receive replies?

19:16 <Marijn[m]> aka_: what about it?

19:16 <aka_[m]> https://lists.sr.ht/~postmarketos/upstreaming/patches/37534

19:18 <Marijn[m]> aka_: yes, again, what about it?

19:19 <aka_[m]> what do you think of dropping usage of 28nm femto driver and using 8916 one

19:19 <aka_[m]> just like recommended by Stephan

19:19 <Marijn[m]> Correct, that's what he's proposing

19:20 <Marijn[m]> Anything you want to add to that?

19:20 <aka_[m]> nothing, just asking if this is possibility

19:21 <Marijn[m]> I had a similar chat with Mis012 about that just yesterday, and told him I'd test that, so yes.

19:21 <aka_[m]> well

19:21 <aka_[m]> guess where it started

19:21 <Marijn[m]> Since minecrell[m] suggested the same thing, might as well

19:21 <aka_[m]> me trying to do things proper way with overriding that register and having Mis012 to do upgrades to driver

19:21 <aka_[m]> then we noticed its wrong

19:22 <aka_[m]> and had some chat with minecrell, somehow Mis012 failed to deliver and i see he had chat with you

19:22 <aka_[m]> so thats quick recap on why i ask

19:23 <aka_[m]> i have device with 8976 you know and im also interested in sending dts for 6.3

19:23 <aka_[m]> Mis012: oh hi

19:23 <Marijn[m]> I also noticed that while porting 8976, but never got to reverting this patch and sending it until now, and never bothered to test the existing nor omitted writes as it "just works"

19:23 <Marijn[m]> Maybe otg might not or something else?

19:24 <Marijn[m]> aka_[m]: Yes please send your DTS, we'll try to send mdp5 soon but ehh iommu..

19:24 <aka_[m]> my only pain was usb was not really getting kicked in if i rebooted phone and then launching linux without replugging usb

19:24 <Marijn[m]> At least all the driver support sent by Angelo and me landed years ago 😅

19:24 <aka_[m]> not sure if related to phy or tusb somehow does not get reset

19:24 <Mis012[m]> 8916 isn't femtophy, it's picophy iirc?

19:25 <aka_[m]> was pico

19:25 <Mis012[m]> picophy is a different IP block...

19:25 <aka_[m]> it appears "API" is same

19:26 <Mis012[m]> pretty sure I checked that and it wasn't

19:26 <aka_[m]> and wasnt qusb also some kind of their IP?

19:26 <Marijn[m]> aka_[m]: By the way don't bother with Linux versions, just use -next and send things as soon as they are ready

19:26 <minecrell> Mis012[m]: the PHY driver used for msm8916 isn't specific to one particular "IP", it's a fairly generic ULPI PHY driver

19:27 <minecrell> it doesn't have pico specific code atm

19:27 <Mis012[m]> oh, you mean the ULPI part

19:27 <Marijn[m]> Things will get reviewed by maintainers and external contributors whenever there's time, and picked up whenever it's acceptable/accepted. No point aiming for kernel versions or you might get disappointed

19:27 <aka_[m]> ulpi is somehow written via host controller to phy or what exactly

19:27 <Mis012[m]> the femtophy driver is specifically for femtophy

19:28 <Mis012[m]> resp. for qcom's register interface to femtophy

19:28 <Marijn[m]> So if you have a minimal boots-to-uart dts ready, send it sooner rather than later ;)

19:28 <Mis012[m]> since femtophy doesn't contain registers

19:28 <Mis012[m]> but qcom connected a lot of it's wires to registers

19:28 <aka_[m]> Marijn[m]: well i would love to be able to send dts with mdp set up already but no iommu so yea

19:29 <Marijn[m]> For that mdp first needs to land in soc dts.... Don't depend on it

19:29 <aka_[m]> why not send mdp iommu-less first

19:29 <Mis012[m]> for the femtophy part, 8976 basically needs no quirks while 404 needs quite some quirks

19:29 <aka_[m]> then assign it once context banks can be defined

19:30 <Marijn[m]> aka_[m]: Theoretically that shouldn't work, neither the dma nor vig pipes?

19:31 <Marijn[m]> We were thinking of sending it with a "depends on link to iommu patches" regardless

19:31 <aka_[m]> hmm, iommu patches arent they required mostly for gpu one due to asid=0?

19:31 <aka_[m]> 8953 have already apps landed

19:31 <Mis012[m]> for example 404 POR for some reason sets it to the wrong ULPI bridge vs plain UTMI mode, since it's connected to dwc3 on 404 which uses UTMI iirc? while 8976 is connected to something that uses ULPI, was that qusb maybe

19:32 <aka_[m]> Mis012[m]: ci-hdcr(?) as host

19:32 <Mis012[m]> so the driver needs to set the right values since POR values are broken

19:32 <Mis012[m]> aka_: right, chipidea

19:32 <Mis012[m]> that's the one

19:33 <Marijn[m]> aka_[m]: Not probe the driver and leave bootloader context banks?