ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
svarbanov has quit [Server closed connection]
svarbanov has joined #linux-msm
joelselvaraj has quit [Server closed connection]
joelselvaraj has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
Guest112 is now known as Rayyan
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #linux-msm
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #linux-msm
<aka_[m]> So i rebased fork of 8953 over next and im getting CLK errors from 14nm PLL DSI PHY.
<aka_[m]> 23.289797] dsi0n1_postdiv_clk: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
<aka_[m]> [ 23.289828] WARNING: CPU: 6 PID: 1037 at drivers/clk/clk-divider.c:139 divider_recalc_rate+0x84/0xb0
<aka_[m]> ok found cause i think, there was commit adding "ref" clock to dsi_phy_pll code and i didnt have this clock passed in dts
<Mis012[m]> so it's going surprisingly well?
<aka_[m]> [drm] *ERROR* [CRTC:63:crtc-0] commit wait timed out
<aka_[m]> wasnt it this error which other porting ppl to sdm660 encounter?
<Mis012[m]> spoke too soo?
<Mis012[m]> *soon
<aka_[m]> ok, screen is working with next
<aka_[m]> and touchscreen finally probe just fine
<aka_[m]> yey
<Mis012[m]> see, some days are not just pain
<aka_[m]> phosh bit slow
<aka_[m]> ok but gpu is working
jhovold has quit [Ping timeout: 480 seconds]
<z3ntu> <aka_[m]> "ok, screen is working with next" <- can you share fix? I'm actually seeing exactly the same
<aka_[m]> wifi is broken
<aka_[m]> due to smem states
<aka_[m]> z3ntu: if you want you can send me dtb dumped from fdt so i can add FP to
<aka_[m]> then later it can be added to org
<aka_[m]> oh yabe im not supposed to post it here XD
<aka_[m]> thought its pmos room
<Mis012[m]> well, if it's the 8.9.1.6 approach, I guess it's as sane as it can be?
<Mis012[m]> did anyone try using the secret mipi dsi commands that let you read out panel info yet?
<Mis012[m]> I wonder if it wouldn't be quite acceptable to model it as a mux in mainline
<Mis012[m]> though I guess mainline only has the concept of a mux that it can control?
<Mis012[m]> shouldn't be too far-fetched to add the concept of a mux that it cannot, though
<Mis012[m]> would also work for all kinds of add-in cards I guess?
<Mis012[m]> well, more like swap-out, but that's more likely to be the case anyway
anholt has quit [Remote host closed the connection]
<minecrell> Mis012[m]: for panel detection or what exactly?
<Mis012[m]> well, for example
<Mis012[m]> seems like it fits
<minecrell> I suspect there are tons of panels out there which don't follow the standard there
<Mis012[m]> well...
<minecrell> I just need to look at a couple of panel drivers to see what terrible mess some are doing, reinterpreting the meaning of standard commands to set hardware-specific registers
<Mis012[m]> what I was suggesting with the mux is that the device tree describes possible things that could be behind the mux
<Mis012[m]> and then a mux driver will tell Linux how to check which of those thing is currently being the mux
<Mis012[m]> *things
<Mis012[m]> and if the way to check which panel you have is too ugly, you can maybe have lk2nd set some unconnected gpios and use that as the mux selection /hides
<minecrell> or you just make your bootloader present a valid device tree to the operating system :p
<Mis012[m]> well, more like you could have a dummy mux where the device tree needs to be edited by lk2nd, yeah
<Mis012[m]> but at least you would have the device tree correctly model that there are several possibilities
<minecrell> the thing is, there isn't a "mux", so adding that to the DT won't make it represent the hardware any better
<Mis012[m]> well... it's not a mux where Linux controls the selection signal
<minecrell> you just have one panel
<minecrell> there is no mux
<Mis012[m]> it's technically a mux where Linux needs to check the selection signal to see which thing is actually connected
<Mis012[m]> maybe mux is not the right word, and it would need a different set of drivers than the mux ones in mainline
<Mis012[m]> but I think it's a concept that makes sense to have in device trees
<Mis012[m]> minecrell: and just because the panel drivers don't use the standard secret MIPI commands, doesn't have to mean they didn't still implement that stuff for compliance reasons
<Mis012[m]> wouldn't be the first time downstream drivers use the sw wrong
<Mis012[m]> *hw
anholt has joined #linux-msm