ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<qzed>
and the test pattern now looks like I guess it should (rgb + white + black squares)
<bamse>
the UCSI_GLINK is replaced by a new fangled design, just haven't moved it to the laptop branch yet
<qzed>
ah, neat
<bamse>
nice, both the images and the test pattern indicates that the dp link is good now
<bamse>
can you exit to a console and run modetest -s 32:2880x1920 ?
<bamse>
that will avoid any potential issues from the gpu
<bamse>
the 32 can be found using modetest -c
<qzed>
sure, one sec, seems arch doesn't ship that and I need to build it
<qzed>
it does show some test pattern
<qzed>
not sure exactly how it should look, seems maybe a bit squished but no artifacts as far as I can tell
<qzed>
okay, going from images I found online, it seems to behave as expected
<bamse>
okay nice
<qzed>
thanks again for all your help! if I'm ever in texas (?) I definitely need to buy you a couple of beers
<bamse>
qzed: so in that screenshot, are all textures just garbage?
<qzed>
it looks that way, yes
<bamse>
hmm, odd, i don't think i've ever seen that problem
<bamse>
but i think i have to hand you over to robclark for some suggestions on that
<qzed>
I'll probably have to iron out a couple of other kinks before that, kernel oopses every second boot or so if I don't manually load panel-edp and msm late (and in that order)
<qzed>
but I'm confident we can figure all that out
<bamse>
yeah, i had problems with that too...currently have the panel builtin to work around that
<qzed>
ah, that's clever xD
<bamse>
you have the hpd_config_intr() call from dp_display_unbind() commented out, right?
<qzed>
that sounds familiar, but let me check
<qzed>
yes, that's commented out
<bamse>
i think that and the reset are required
<qzed>
ah okay
<bamse>
if the dp driver fails to probe on first attempt, we get that oops about kfree()...and it moves in an start turning off the clocks and stuff
<bamse>
so first it will do hpd_config_intr() and write to a register without first turning on the ahb clock
<bamse>
and then it will turn off some clocks which are used by the running display from boot
<qzed>
ah, I guess that makes sense
<qzed>
funny enough, I have a hard time reproducing that with rts/cts flow control turned on on my usb-serial bridge... guess that slows things down sufficiently xD
<bamse>
hehe, that wouldn't be the first time
<robclark>
bamse, qzed: those screenshots.. it looks like something is mismatched in UBWC configuration between gpu and dpu
<bamse>
robclark: i was under the impression that someone fixed that, because i didn't specify the debug flag for that last time i booted my flex 5g
<bamse>
qzed: can you try starting the graphical environment with FD_MESA_DEBUG=noubwc ?
<robclark>
FD_MESA_DEBUG=noubwc would confirm that.. but there are some SoC specific configurations that need to be in agreement between gpu and display (and other blocks)
<qzed>
bamse robclark: that doesn't show artifacts
<bamse>
qzed: maybe my testing is bad then and this is still a sc8180x problem
<robclark>
I would *guess* that it is the same for sc8180* but could be wrong.. on the GPU side, see a6xx_set_ubwc_config(), you might need to add something there..
<bamse>
i agree
<robclark>
dpu side, it looks like it is scattered in a few places
<robclark>
in particular a6xx_set_ubwc_config() doesn't appear to have any a680/a690 specific cases.. which seems dubious
<bamse>
a640_family is 680 as well
<qzed>
i'll see if i can figure something out via the windows driver tomorrow... already have pinned down gmu register access, so I can maybe figure out the gpu register access as well
<robclark>
bamse: I assume some of it depends on ddr config.. doesn't sc8180* have 4 channels vs 1 or 2 channels for everything else?
<bamse>
8
<robclark>
or, ok, I might be off by a factor of two ;-)
<bamse>
but yes it's LPDDR4...so that comment that is sprinkled in a few places about ddr4 seems relevant to adhere to
<qzed>
I've set the values as described where LPDDR4 was mentioned and that doesn't seem to be enough
<robclark>
keep in mind that both display and gpu (and later, as they are enabled, other blocks) need to be in agreement
<robclark>
one option, probably dpu should only advertise support for the QCOM_COMPRESSED modifier (dpu_plane_init() passes this to drm_universal_plane_init()) on devices we know to configure ubwc properly
<robclark>
that would let us disable ubwc during bringup of new SoCs without needing userspace hacks
<bamse>
robclark: but does the ddr4 notations have any visual outcome, or is it just improved timing?
<robclark>
I'd guess at a minimum, if display and gpu disagree there would be visual outcome ;-)
<robclark>
if they both agree but agree wrongly it could be a perf thing
<bamse>
don't think i understand the impact of those bits then...
<robclark>
heh, I guess you have more docs about it than I do ;-)
<bamse>
yeah, but i didn't think i had to care ;)
<robclark>
I wonder if there is a sane way to dump regs (ie. devmem type thing or whatever) on windows.. those regs are all static config so for SoCs that aren't in android kernel it would be useful to be able to dump how windows configures them
<bamse>
that would be useful, because the only reference we have is from automotive, and they don't run things at the same clocks etc
<robclark>
for ubwc in particular I wouldn't expect clks to be related.. more like optimal memory access pattern tuning type things
<bamse>
ok, then we might be able to just scrape the downstream source for it...
<bamse>
although that's mostly just painful
<robclark>
I've been downstream-dumpster-diving for years ;-)
<bamse>
i've spent a considerable amount of time in that dumpster lately as well
<robclark>
;-)
<bamse>
and now i can get picture on the 6 native displayport outputs of my sc8280xp board :)
<bamse>
and the edp panel on the laptop...
<robclark>
6x dp out.. that is pretty nice!
<bamse>
6 native...then there's two dsi-to-dp bridges...and two usb-c
<robclark>
that is way more monitors than I have :-P
<bamse>
same here...
<bamse>
but i have this urge of scraping together what i have and see if i can start wayland with them connected
<bamse>
the platform has 2 instances of mdss, so i wasn't sure how drm/msm would behave, but it seems to be working ok
<bamse>
that said, i've only cycled a single monitor through the connectors (across the two instances)...
<robclark>
oh, that is unique
<bamse>
modetest though only see one of the instances, so i'm not sure what that means
<robclark>
are you representing that as two drm devices?
<bamse>
yeah, just have two copies of qcom,sc8280xp-mdss in dt
<bamse>
and then show up as individual cards in /dev and /sys
<robclark>
ok, modetest does (iirc) have cmdline args to point it at a specific drm device..
<bamse>
ah okay, that makes sense
<bamse>
i guess the real question is what wayland will do...but i need to escape the ramdisk for that
<robclark>
not really sure how we want to map a single gpu to two display...
<bamse>
ahh interesting, haven't thought that far ahead yet
<robclark>
so there is some mesa bits for supporting decoupled display and gpu.. so far we have only used that for a2xx+im5
<bamse>
i got dp working on both instances, so i'll probably pause it there, clean up what i have and flush out the patches for that...so that we have display on the laptop - which only uses one instance
<robclark>
yeah, starting with one instance is sensible.. tbh I'm not entirely sure what we should do with two
<bamse>
run sl(1) on a really really wide terminal, of course
<bamse>
or you meant, how to implement it?
<robclark>
latter, yeah ;-)
hexdump0815 has joined #aarch64-laptops
<robclark>
bamse: ok, rough idea, the drm device w/ 2nd display and no gpu should expose itself the userspace with a different device name so userspace realizes it is a kms only devices.. and then *some hand waving*
hexdump01 has quit [Ping timeout: 480 seconds]
<robclark>
mainly we want mesa to bind to the device that actually has a gpu
<bamse>
robclark: what's involved in that binding?
<bamse>
or, what's the actual relationship between the two pieces?
<robclark>
currently, it is the name that the GETVERSION ioctl returns
<bamse>
right, but "why does it matter"?
<robclark>
mesa will look for drm dev w/ name "msm" and try to use it as gpu
<bamse>
ahh okay, so it's only used to find the gpu?
<robclark>
that comes from drm_driver::name fwiw
<robclark>
yeah, because "video cards" ;-)
<bamse>
but there's no relationship between the two beyond that, right?
<robclark>
so if thing without gpu doesn't have name=="msm" we can hopefully re-using the renderonly stuff
<bamse>
what about shared memory objects etc?
<robclark>
yeah it is mostly about how mesa figures out which driver to load
<robclark>
there is dmabuf buffer sharing for the rest
<bamse>
that's what i assumed
<bamse>
seems like it's not too much hand waving for that part then...
<bamse>
i got some more stuff to flush out, then i have to take a look at making the gpu kick...then we'll see about this problem
<bamse>
i don't have a usecase, beyond trying to take a picture of a bunch of monitors driven by a single snapdragon
<robclark>
yeah, I think get 1 mdss working first
<bamse>
right, that's the one we care about...
<robclark>
how does daisy-chaining a bunch of dp displays work?
<bamse>
some of the qualcomm dp controllers have support for 2 streams
<robclark>
presumably at some point you need both mdss driving a single dp?
<robclark>
or is that not supported?
<bamse>
the typical usecase is that you have a single port driving > 1 panel
<bamse>
where > 1 is 2 in qualcomm's hardware design
<robclark>
ahh
<bamse>
but similar to dsi you can bond two dp connections together to some ultra-wide monitors
<robclark>
ok, so ignore that use case
<robclark>
yeah.. I think that is becoming less common fortunately
<bamse>
and it's stated that there's some wire between the two instances to synchronize things and make that possible across the two instances
<bamse>
in our world, but i think that you find that when you run a 10k dashboard panel in your car or something
<robclark>
but dp does let you daisy chain.. and I think that is the use-case for lotsa dp out on intel is daisy chain
<bamse>
yes, that's multistream (mst)...
<robclark>
yeah, for auto splitting the display makes more sense, because you pass-thru map one for vm
<bamse>
so you can send multiple dp streams over a single physical connector
<bamse>
that works by you having 2 intf's connected to a single dp controller
<bamse>
e.g. on sc8180x you can see that there's 3 intfs associated with the 2 usb-c dp-controllers...
<bamse>
so you can run 2 monitors in daisy chain + a single monitor
<bamse>
if you have sufficient mixers and sspp instances etc
<robclark>
ok.. as long as two mdss don't route into single dp.. in that case we would have to make drm driver more aware of >1 mdss
<bamse>
no, the dp instances are associated with the mdss
<robclark>
ok
<bamse>
so you have dpu, dsi, dp controllers for each mdss, then those are routed to a bunch of phys
<bamse>
but no crosstalk there
<bamse>
time to get some sleep here now, i'll probably ping you once i've taken a deeper look at the downstream kgsl patches
<bamse>
have a nice evening
<robclark>
sg, gn
<HdkR>
Can confirm, Snapdragon 888 board doesn't support my 8k tiled display :P
iivanov has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
falk689_ has joined #aarch64-laptops
falk689 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
fleebs has quit [Read error: Connection reset by peer]
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
systwi_ has joined #aarch64-laptops
systwi has quit [Ping timeout: 480 seconds]
falk689_ has left #aarch64-laptops [#aarch64-laptops]
falk689 has joined #aarch64-laptops
systwi has joined #aarch64-laptops
systwi_ has quit [Ping timeout: 480 seconds]
systwi has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
iivanov has quit []
falk689 has quit [Remote host closed the connection]