ChanServ changed the topic of #linux-msm to:
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-msm
cxl000 has quit [Quit: Leaving]
sergi has joined #linux-msm
Daanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #linux-msm
Daanct12 has joined #linux-msm
Daaanct12 has quit [Read error: Connection reset by peer]
cxl000 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
svarbanov has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
djakov_ has quit [Remote host closed the connection]
djakov has joined #linux-msm
<Mis012[m]> minecrell: hm, there's no-downtime switching implemented for PLLs?
<Mis012[m]> could use that for SSCCC...
pespin has joined #linux-msm
<konradybcio> depends on the pll
<konradybcio> some support that
<konradybcio> stromer can change frequency without a shutdown
<Mis012[m]> I'd assume the SSC Q6 PLL depends on the main SSC PLL not dying?
<Mis012[m]> as does the AHB connection
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
sergi has quit [Ping timeout: 480 seconds]
<Mis012[m]> lumag_: lumag: lumag__: (sorry, not sure which handle is the correct one xD )
<lumag> Mis012[m]: hi, hi
<Mis012[m]> it seems that with QSIP7c, qcom uses the usb3 combo phy lines as permanently displayport, and conncects that to PS8743BQFN40GTR-B1
<Mis012[m]> so could presumably do the same thing externally
<Mis012[m]> lumag: guess it makes sense that it would be qcom themselves to do this, nobody else dares to use the full potential of qcom hw :P
<lumag> Ps8743 is a usb-c /altmode switch
<Mis012[m]> yeah, and they're using the SoC's usb3/DP combo phy as a dedicated DP phy
<lumag> Ah, its a redriver
<Mis012[m]> it clearly does muxing
<Mis012[m]> and it seems that it could totally be implemented externally
pespin has quit [Remote host closed the connection]
<Mis012[m]> lumag: since it seems like it might be a reference design thing, do you have any idea what arch CPU IT5571 uses?
<Mis012[m]> I assume I can't haz datasheet, but I still don't even know what CPU arch the IT8225 in my x86 laptop uses so that would probably be a good start
<Mis012[m]> I bet the chromebooks use a different EC :/
<Mis012[m]> would have cros-ec support for free if not
<Mis012[m]> npcx7m6fc for lazor it would seem...
<lumag> Mis012[m]: let me think...
<Mis012[m]> lumag: fwiw, in the IT8225 it might be more useful... seems that in the IT5571 case the eSPI is NC and it uses i2c slave for ACPI ugliness...
<Mis012[m]> not sure if cros-ec supports that
<Mis012[m]> seems like it would be quite limiting
<lumag> I don't even think that you would need any kind of switch for the direct connection.
<lumag> And I'd you don't have aux, you can completely drop that part too.
<Mis012[m]> lumag: well, yes, but not sure if there are ICs that do it without the switch
<lumag> Redriving?
<Mis012[m]> lumag: last time you said that AUX is actually required for in-spec DP monitors?
<lumag> You would like to connect the dp monitor directly, don't you?
<Mis012[m]> yes, that would be nice
<Mis012[m]> well, not me specifically, my device has the hw
<Mis012[m]> but there are some other people who could use this
<lumag> I think so. The DP driver does transfers over dp, like writing the edid checksum.
<lumag> *over aux
<Mis012[m]> well, I guess if there was just a DP AUX master IC, that would be enough
<Mis012[m]> preferably usb-connected because god forbid a vendor exposes unused useful stuff like i2c...
<lumag> According to wiki, aux is not the i2c per se. It uses different encoding for the signals
<Mis012[m]> well, yes, but I assume that if there is such a thing as DP AUX master IC, it will be an i2c slave and not USB one
<Mis012[m]> though so far it seems that it's not a thing, or I don't have the right key words
<Mis012[m]> ok, I take it back, finding a usb-connected one was even easier than an i2c-connected one 🤣
<Mis012[m]> looks like someone is encroaching on qphy™️
<lumag> The last link doesn't work for me.
<lumag> If can get a grip of the details, maybe it would be easier to create an i2c-to-aux converter using the FPGA.
<lumag> For me this is a task for the logic array
qyousef has joined #linux-msm
qyousef_ has quit [Ping timeout: 480 seconds]
<Mis012[m]> seems like there ought to be a cheaper way...
<Mis012[m]> unless you can use some REALLY small FPGA
jhovold has quit [Ping timeout: 480 seconds]