ChanServ changed the topic of #linux-msm to:
<ndec> anholt: are they new devices? have you tried to reflash them with recovery bootloader?
<anholt> ndec: brand new. how would I reflash if they don't get to fastboot?
<ndec> with the usb flashing tools
<anholt> I'll give that a try tomorrow. thanks!
<ndec> also, there is a switch config to decide if the uart goes on the LS expansion, or to the onboard USB/FTDI thingy
<ndec> " Switching DIP_SW_0, switch 2 to Off makes console be redirected to LS1 UART1." so you need that to be ON.
<anholt> that one defaulted to useful. the qdl flashing has recovered both boards, thanks!
<anholt> (also, very glad that there's this nice ftdi on board instead of having to solder a whole bunch of LS expansion connections)
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
duuooosla[m] has joined #linux-msm
pevik_ has joined #linux-msm
enok has quit [Remote host closed the connection]
enok has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
svarbanov has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-msm
svarbanov has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
eodcat has quit [Quit: WeeChat 2.1]
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
lumag_ has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
pevik_ has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
<calebccff> lumag: I saw your patches for WIP displayport support on db845c, I have a phone with the same feature and wanted to give it a go, is there anything else missing for it?
robertfoss has joined #linux-msm
pespin has quit [Remote host closed the connection]
<Mis012[m]> calebccff: btw, do you have any idea what the "missing part" is on phones where it doesn't "just work"
<Mis012[m]> in theory all you need are the USB3 lines
<Mis012[m]> though there are vendors who only connect USB2... 🤡
<lumag_> calebccff, yep. The PMIC part to negotiate altmode, orientation, etc.
<lumag_> calebccff, bryanodonoghue did the implementation for the RB5, but sdm845 (pm845) uses different set of registers.
<Mis012[m]> lumag_: what's stopping us from just forcing the DP mode? I guess knowing the orientation might not be trivial, but knowing that have plugged in a DP adapter certainly is
<Mis012[m]> could be useful for boards where the PMIC part is botched
<lumag_> Mis012[m], you have to tell the DP dongle to switch to the DP.
<lumag_> To tell it, which lanes to use, etc.
<lumag_> This is done using the power delivery protocol.
<Mis012[m]> lumag_: well, I guess at that point you would have to just make a dumb usb-c to DP shim?
<Mis012[m]> I assumed the dongle would have those lines connected permanently
<lumag_> No
<lumag_> Each usb-c to DP dongle has this stuff software configurable.
<lumag_> Because it also has to adapt to the DP capabilities of the host, to the orientation, etc.
<Mis012[m]> isn't having lane swapping on both sides redundant? :D
<lumag_> It's not only about lanes swapping.
<lumag_> SBU (aux), voltage levels, etc.
<Mis012[m]> aux is not needed with hardcoded EDID fwiw
<Mis012[m]> and botched boards likely don't have aux connected
<lumag_> Mis012[m], aux is needed to negotiate with DP. At some point the host writes the EDID checksum to let DP sink know that EDID was read corrrectly.
<lumag_> So, I'd forget about broken boards without SBU
<Mis012[m]> sad, HDMI doesn't care whatsoever
<lumag_> Yep
<lumag_> DP-over-USB is much, much uglier.
<Mis012[m]> well, the usb-c twisted pairs are muxed as real DP lines, right?
<Mis012[m]> or would I have to read the spec to get to "well actually"
<Mis012[m]> the aux lines could probably be handled by the dongle if you have to make your own "dumb" one anyway
<Mis012[m]> could even have a usb 2.0 aux controller to be extra fancy
<lumag_> Mis012[m], Then you basically have to implement the special USB 2.0 Type-C port manager (both in hardware and in the driver).
<Mis012[m]> well... I'd be fine with seeing a PoC really :P
<Mis012[m]> just as a middle finder to the OEM who decided that the SoC functionality can go to waste
<Mis012[m]> though what's really wasted is PCI-E, and I can't do much about that :(
<lumag_> Mis012[m], :-(
<Mis012[m]> I wouldn't be suprised if even Jeff the RPi PCI-E guy has a wasted superior PCI-E controller in some phone lying around...
<Mis012[m]> lumag_: fwiw what I care about for *my* niche usecase is whether I can have the HPD line of a HDMI port on a DP-alt-mode+hdmi-adapter routed as a general purpose IRQ
<Mis012[m]> but sadly I wouldn't be surprised if it again depends on the dongle as well...
<lumag_> Mis012[m], not in the generic case. It is the PD message, not a real HPD line
<Mis012[m]> what about the specific case of msm8998?
<lumag_> It's still a PD message
<lumag_> Unless you have a real DP connector
<Mis012[m]> I mean... the SoC even has native HDMI pins where DDC is muxed with i2c and HPD is muxed with an interrupt-capable GPIO
<Mis012[m]> but sadly unconnected, you guessed it
<Mis012[m]> I assume I can hack in a handler instead of whatever Linux would do on the HPD message arriving?
<Mis012[m]> the question is if the SoC will shut off the display out anyway...
<Mis012[m]> which would be pretty sad because I only have one port for both the display and the HPD :P
<lumag_> Mis012[m], in HDMI case, it is true. You can use the display-connector and let it handle a separate GPIO line (not necessary the SoC's HDMI_HPD)
<lumag_> So, if you want to use the SoC HDMI lines, it should be pretty easy.
* lumag_ still has to try fixing the MHL support for Nexus7.
<Mis012[m]> well, in my usecase, since I want the IRQ, I can deal with manually telling it if there's a display connected
<lumag_> Mis012[m], again, true for the HDMI case.
<lumag_> I'm not so sure for the DP, as it involves a lot lot more behind the scenes.
<lumag_> But I'd be glad if that works.
<lumag_> Does msm8998 has separate DP lines or is it the muxed USB SS + DP?
<Mis012[m]> lumag_: using the SoC HDMI lines requires hot air removing the PoP-enabled SoC, reballing it, and adding magnet wires running between the balls
<lumag_> :D :D :D
<Mis012[m]> might as well add a PCI-E connector at that point...
<lumag_> Mis012[m], maybe I'm missing the point, as you were talking about the HDMI at some point.
<lumag_> Please excuse me in such case.
<Mis012[m]> if I lived in the US, I would definitely challange mr. Rossmann to swap an SoC for a blank at least
<Mis012[m]> lumag_: HDMI over DP over usb-c
<lumag_> Mis012[m], then it's just DP over USB-C
<Mis012[m]> the HDMI part should actually give me i2c over aux though
<Mis012[m]> at least
<lumag_> (and the dongle handles all the HDMI stuff on it's own)
<lumag_> I think the dongles look like DP from the source side.
<lumag_> The HDMI part completely doesn't matter.
<Mis012[m]> well... getting i2c over aux for free does matter to me :P
<Mis012[m]> but I guess the HPD part would be identical to DP case, unless dongle decides to go into low power mode based on HPD state 🤡
<calebccff> lumag_: right, that's what i thought. thanks
<calebccff> Mis012[m]: my device has a SW controlled mux for switching the AUX<->SBU orientation, it is hooked up
<Mis012[m]> calebccff: btw could you point nergzd to someone who has android on their 8998, he's reluctant to test the takeover himself
<Mis012[m]> need android userspace to have SSC bus inited for some reason, and we can't init it ourselves on not-ownership-enabled devices
<Mis012[m]> but it seems like it works
<Mis012[m]> obviously hands with ded AHB going to SSC
<Mis012[m]> *hangs
<Mis012[m]> and TZ won't tell you that AHB timeout occured, it will just reboot the device 🤡
<Mis012[m]> so can't really tell why it reboots
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
anholt has quit [Ping timeout: 480 seconds]
anholt has joined #linux-msm
lumag_ has quit [Quit: Leaving]
<calebccff> Mis012[m]: nobody is running AOSP/mainline on msm8998 currently