go4godvin has quit [Quit: Bridge terminating on SIGTERM]
Tooniis[m] has quit []
MatrixTravelerbot[m] has quit []
ichernev[m] has quit [Quit: Bridge terminating on SIGTERM]
RayyanAnsarimatrixorg[m] has quit [Quit: Bridge terminating on SIGTERM]
RayyanAnsari[m] has quit [Quit: Bridge terminating on SIGTERM]
joelselvaraj has quit [Quit: Bridge terminating on SIGTERM]
ajhalaney[m] has quit [Quit: Bridge terminating on SIGTERM]
cmeerw[m] has quit []
Newbyte has quit [Quit: Bridge terminating on SIGTERM]
aka_[m] has quit [Quit: Bridge terminating on SIGTERM]
alikateshethey[m] has quit [Quit: Bridge terminating on SIGTERM]
fevv8[m] has quit [Quit: Bridge terminating on SIGTERM]
z3ntu has quit []
mint[m] has quit [Quit: Bridge terminating on SIGTERM]
Syboxez[m] has quit [Quit: Bridge terminating on SIGTERM]
undev[m] has quit [Quit: Bridge terminating on SIGTERM]
konradybcio has quit []
vknecht[m] has quit []
wfranken[m] has quit [Quit: Bridge terminating on SIGTERM]
jojo_autoboy[m] has quit [Quit: Bridge terminating on SIGTERM]
MartinBotka[m] has quit [Quit: Bridge terminating on SIGTERM]
DavidHeidelberg[m] has quit []
mirsal[m] has quit [Quit: Bridge terminating on SIGTERM]
aedancullen has quit []
travmurav[m] has quit [Quit: Bridge terminating on SIGTERM]
sepkov[m] has quit [Quit: Bridge terminating on SIGTERM]
JoelSelvaraj[m] has quit [Quit: Bridge terminating on SIGTERM]
Marijn[m] has quit [Quit: Bridge terminating on SIGTERM]
Bazsalanszky[m] has quit [Quit: Bridge terminating on SIGTERM]
minecrell[m] has quit [Quit: Bridge terminating on SIGTERM]
ungeskriptet[m] has quit [Quit: Bridge terminating on SIGTERM]
robbbbbb[m] has quit [Quit: Bridge terminating on SIGTERM]
kholk[m] has quit [Quit: Bridge terminating on SIGTERM]
Mis012[m] has quit [Quit: Bridge terminating on SIGTERM]
ivoszbg[m] has quit [Quit: Bridge terminating on SIGTERM]
maxim[m] has quit [Quit: Bridge terminating on SIGTERM]
IvanBelokobylskiy[m] has quit [Quit: Bridge terminating on SIGTERM]
AntoniAloyTorrens[m] has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
aedancullen has joined #linux-msm
ajhalaney[m] has joined #linux-msm
aka_[m] has joined #linux-msm
alikateshethey[m] has joined #linux-msm
Bazsalanszky[m] has joined #linux-msm
cmeerw[m] has joined #linux-msm
fevv8[m] has joined #linux-msm
Guest29 has joined #linux-msm
ichernev[m] has joined #linux-msm
IvanBelokobylskiy[m] has joined #linux-msm
ivoszbg[m] has joined #linux-msm
joelselvaraj has joined #linux-msm
JoelSelvaraj[m] has joined #linux-msm
jojo_autoboy[m] has joined #linux-msm
kholk[m] has joined #linux-msm
konradybcio has joined #linux-msm
z3ntu has joined #linux-msm
mint[m] has joined #linux-msm
Marijn[m] has joined #linux-msm
maxim[m] has joined #linux-msm
minecrell[m] has joined #linux-msm
mirsal[m] has joined #linux-msm
Mis012[m] has joined #linux-msm
Newbyte has joined #linux-msm
DavidHeidelberg[m] has joined #linux-msm
RayyanAnsarimatrixorg[m] has joined #linux-msm
RayyanAnsari[m] has joined #linux-msm
MartinBotka[m] has joined #linux-msm
robbbbbb[m] has joined #linux-msm
sepkov[m] has joined #linux-msm
Syboxez[m] has joined #linux-msm
Tooniis[m] has joined #linux-msm
travmurav[m] has joined #linux-msm
undev[m] has joined #linux-msm
ungeskriptet[m] has joined #linux-msm
vknecht[m] has joined #linux-msm
MatrixTravelerbot[m] has joined #linux-msm
wfranken[m] has joined #linux-msm
Daanct12 has quit [Quit: Leaving]
pespin has joined #linux-msm
Guest29 is now known as go4godvin
jhovold has quit [Ping timeout: 480 seconds]
pespin has quit []
<Marijn[m]>
lumag_: I Rebased my sdm630 Nile series on 5.18 and same as on the msm8956/Loire series: black screen. No hangcheck in dmesg this time though, will have to investigate some more what's up. Android log spam makes dmesg useless after early boot 😬
<Marijn[m]>
It's only 59 patches away from main now instead of some ~80 (patches landed 🥳), that's manageable to clean up and push
<lumag_>
Marijn[m], great :-)
<lumag_>
can you please send kholk's mdp5 fix from that branch?
<lumag_>
Marijn[m], bamse (and IOMMU guys) might scream on me. I'd prefer to put all the details into the driver rather than having them in the dts. This assumes that all devices share the same hyp/iommu config
<Marijn[m]>
lumag_: Shall I split it up? It's quite a large and messy patch
<lumag_>
Marijn[m], up to you
<Marijn[m]>
lumag_: It's not my patch so I'll have to look at it for a bit :)
<Marijn[m]>
Also would love to have display working on this device on 5.18 before sending display-related changes... Even if they work on 5.16
<aka_[m]>
is display for you broken on rc5 or next?
<aka_[m]>
Im going to rebase 8953 tree tomorrow to check my device.
<Marijn[m]>
rc4/5
<Marijn[m]>
But it's only GPU afaik
<Marijn[m]>
I haven't checked swrast nor TPG nor fbcon yet
<Marijn[m]>
(Because I keep forgetting which out of the gazillion ways to enable fbcon I should use)
<aka_[m]>
Mis012: got some more ideas on that driver?
<bamse>
Marijn[m]: the "va size quirk" patch...any reason why that is not just dma-ranges in /soc ?
<bamse>
Marijn[m]: or is that just not reducing the iova address space to 39 bits instead of the 40+ reported by hardware?
<lumag_>
Marijn[m], I've been working on top of msm/msm-next
<lumag_>
The display works here
<Marijn[m]>
bamse: Is `va_size` initialized from DT? Then yes that makes more sense I think... I'll either have to check/test the code or ask Angelo :)
<Marijn[m]>
lumag_: With or without GPU? What are you using to test DRM/KMS plainly?
<bamse>
Marijn[m]: the iommu will report that it can do 40 bits, then as you're allocating a iova the dma-ranges for the bus is considered
<lumag_>
Marijn[m], modetest -s mostly
<lumag_>
fbcon, etc
<bamse>
Marijn[m]: e.g. on sdm845 the iommu says 40 bits, but the upper 4 address bits are lost on the bus (at least on some of the busses)...so we use dma-ranages to pull that down to 36 bits
<lumag_>
I did get up to the smmu/gpu patches yesterday.
<Mis012[m]>
aka_: which driver
<aka_[m]>
Mis012[m]: femtophy
<Mis012[m]>
working on it, when not procrastinating
<bamse>
Marijn[m]: so what the smmu patches says is that _some_ context banks are read-only? or reserved?
<bamse>
Marijn[m]: or is it saying that all the context banks are read only and we should just run with the existing configuration?
<Marijn[m]>
lumag_: Thanks, I'll see if there's a void-linux package for modetest
<lumag_>
Marijn[m], it comes from libdrm source (libdrm-tests or something like that)
<Mis012[m]>
did kmscube fall out of fashion?
deathmist1 has quit [Remote host closed the connection]
deathmist1 has joined #linux-msm
<Marijn[m]>
Mis012: How about `cat /dev/urandom > /dev/fb0`
<lumag_>
Mis012[m], it requires gpu
<Mis012[m]>
surely not with swrast?
<lumag_>
Mis012[m], then it's just no point
<lumag_>
with modetest I can enable several planes with different formats, scaling, etc.
<Marijn[m]>
lumag_: kmscube should not require a GPU? That's the whole point of it afaik, purely using DRM and KMS
<Marijn[m]>
Otherwise defer to glxcube or vkcube
<Mis012[m]>
you still get a cute cube though, surely that's worth something?
<lumag_>
Marijn[m], I think it uses gl
<lumag_>
Definitely.
<Marijn[m]>
It uses EGL indeed 🤦♂️
<lumag_>
So, it was failing e.g. on db820c w/o the clk_gfx3d fix
<Marijn[m]>
I thought it was a pure helper... Nah similar to glxgears but without the window-manager/compositor part
<Mis012[m]>
well... if you have a compositor running, you probably don't need additional programs to test if your 3d acceleration works :P
<lumag_>
I'm not going to put weston into my initramfs
<lumag_>
Especially as the ifc6560's abl is picky on the initramfs size
<Mis012[m]>
just saying that not needing a compositor is a legitimate distinguishing feature
<Mis012[m]>
should just port u-boot
<lumag_>
Marijn[m], kholk[m]; btw, regarding the mdp5 patch. According to the sdm660-mdss.dtsi, the sdm660 has source split.
<lumag_>
So that part was correct
<Mis012[m]>
surely there are better references than downstream which is known to heavily imply things which are not true? :(
<Marijn[m]>
<Mis012[m]> "well... if you have a compositor..." <- Yeah of course, that's what it is for. I just long for a tool that uses pure DRM and no GPU
<Marijn[m]>
But w.e., display is up now
<Mis012[m]>
Marijn: well, worst case there's still swrast :P
<Marijn[m]>
bamse: Apologies for skipping over your IOMMU comments, I'll test this out with dma-ranges and report back soon
<Marijn[m]>
(On Android, that is - gnome on a508 is happy)
<Marijn[m]>
I vaguely remember one of the allocators being fixed to not use ashmem anymore, but maybe that will only land in Android T (and perhaps it is time to migrate to #_oftc_#aosp-developers:matrix.org / #linaro-android)
<Mis012[m]>
>ashmem
<Mis012[m]>
sounds like android problems
<Mis012[m]>
and android really doesn't deserve being treated as equal here
<Mis012[m]>
considering the crimes against humanity they still commit
<Mis012[m]>
and of course GKI
<Marijn[m]>
Mis012: Yes I'm more and more leaning towards just using a Linux distro
<Marijn[m]>
Android as a concept on mainline was fun, but I won't keep up with all their changes
<Marijn[m]>
Nor was GKI ever a good idea, it's just another way to cheat yourself out of upstreaming hardware support yet again
<Mis012[m]>
and probably cheat yourself out of complying with GPL
<Mis012[m]>
but we'll see if someone tries to play that card
<aka_[m]>
Marijn[m]: there is bright side.
<aka_[m]>
Google might roll kernel updates via playstore
<aka_[m]>
lts updates but still
<aka_[m]>
s/lts/LTS/
<Marijn[m]>
Updates are updates, but we won't be wasting so much time if more effort was put in upstreaming things properly (which really is happening nowadays with newest Qcom socs)
<aka_[m]>
still what is being upstreamed is just a drop in ocean
<aka_[m]>
only 8XXX and Compute
<aka_[m]>
rest is pure community
<Mis012[m]>
>Google might roll kernel updates via playstore
<Mis012[m]>
sounds like something android downstream users would care about
<Mis012[m]>
so irrelevant by definition :P
<aka_[m]>
10minutes kernel build after upgrading to ryzen 5 5600
<aka_[m]>
so good.
<Mis012[m]>
glad you're enjoying it :P
<Marijn[m]>
Nice!
<Marijn[m]>
(You need to trim your defconfig some more maybe, I expected it to be faster)
<aka_[m]>
from 40 minutes before, thats big diff.
<Mis012[m]>
Marijn: who doesn't want nouveau to use the GPU that you're going to hook up to the unconnected SoC balls :P
<Marijn[m]>
40 minutes? That's some dedication, at least you can dirty-build after
<aka_[m]>
ok so 5.18_rc5 booted to phosh.
<aka_[m]>
should try that tip with disabling binning maybe it will work on a510
<konradybcio>
>10minutes kernel build after upgrading to ryzen 5 5600
<konradybcio>
that's a looot, my 2700x does like 3 minutes and your cpu may be actually faster, especially considering my lack of cooling.. want my defconfig?
<Marijn[m]>
<aka_[m]> "should try that tip with..." <- Pretending it's a530?
<aka_[m]>
on a506 we do
<Marijn[m]>
Ugh you may run into GMEM size mismatches
<Marijn[m]>
There's not much else different in Mesa at least - gmem size may even be configured in kernel nowadays
deathmist1 has quit [Read error: Connection reset by peer]
deathmist1 has joined #linux-msm
<Marijn[m]>
lumag_: Good news, I rebased and cleaned that entire SDM630 tree. I don't know if all patches from the 5.10 have remained, as this branch has seen many rebases but the rest should have landed thanks to Angelo and Konrads relentless efforts. At least this branch has somewhat usable display, connects to my BT headphones, and is able to play rickroll from youtube over USB network sharing :)
<Marijn[m]>
bamse: Unfortunately removing Angelo's 39-bit VA hack and replacing it with `dma-ranges = <0 0 0x80 0>; /* 39 bits */` in the DT under `soc` makes the device not fully boot. Unfortunately the UART is not replying anything which I'll solve tomorrow so that I can give you more info
<Marijn[m]>
Other than that it's well beyond bedtime and this sdm630 doesn't look a whole lot like the msm8976 that I promised...