<hexdump01>
tuxd3v: i think it depends a bit on the loading order of the different drm driver levels (i.e. which is =y or =m) ... this is working well for me with regular xorg
hexdump01 has left #linux-sunxi ["WeeChat 1.9.1"]
sunshavi has quit [Ping timeout: 265 seconds]
jstefanop has joined #linux-sunxi
reinforce has joined #linux-sunxi
jstefanop has quit [Ping timeout: 240 seconds]
daregap has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hlauer has joined #linux-sunxi
cmeerw has joined #linux-sunxi
gsz has joined #linux-sunxi
cmeerw has quit [Ping timeout: 248 seconds]
fl_0 has quit [Ping timeout: 250 seconds]
fl_0 has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
ldevulder_ is now known as ldevulder
apritzel has joined #linux-sunxi
tnovotny has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 265 seconds]
mossroy has joined #linux-sunxi
mossroy has quit [Remote host closed the connection]
<apritzel>
maz: or are you looking for another branch?
<maz>
apritzel: nah, that's the one I needed. stupidly overwrote the lkvm binary on my FVP fs, needed to rebuild it, and couldn't find a local copy of it.
<maz>
apritzel: now back up and running, I guess I'll spam you with a NV update post -rc1.
<apritzel>
maz: ah, was my next question, happy to test it again
<maz>
apritzel: I've pushed out kvm-arm64/nv-5.13-WIP, which I'll rebase again atop -rc1 once it is out.
<maz>
apritzel: if you still have access to the HW, feedback most welcome.
<pnill>
apritzel: For clarification that winbond's data sheet says it is SLC.
<pnill>
haven't gotten around to playing with it yet and probably won't for at least a month or two
<pnill>
but thought that was interesting, so I'm wondering if I can like 'dual' boot in some way between linux mainline off USB, and normal via a custom u-boot written to the nand
<sunshavi>
tuxd3v, did u istalled xorg-server-git?
<apritzel>
megi: so the H5 does not have that hidden /2 postdiv, for instance, but it has new_mode
<tuxd3v>
anarsoul, indeed the system have dependencies and if I remove the old ones it also removes essential xorg packages :/
<megi>
some clocks are sourced from pll 4x instead of 2x, (but the code assumes otherwise), and it only works because of differences in new/old mode and some defaults in some pll and mmc registers. And these defaults differ across socs. I barely remember, but I think user manuals are correct in the description of clock dividers for mmc.
<megi>
and some hidden internal pre-dividers in mmc block, that's only enabled in new mode, or whatever
<megi>
it's a bit of a mess :)
<megi>
even kernel clock driver has it wrong
<megi>
but it works by accident
<megi>
next time I should be more verbose in my code comments, documenting my findings
<apritzel>
megi: I fixed the wrong PLL6 factors already
<megi>
I barely understand now what I meant by all those numbers :)
<megi>
it's not just factors, that's just a small offset
<apritzel>
so maybe that disables the "works by accident" feature
<megi>
right?
<megi>
or was it halving the freq?
<apritzel>
yes
<apritzel>
PLL6 vs. PLL6x2
<apritzel>
on some SoCs
<megi>
allright then
<apritzel>
megi: well, just wanted to give you a heads up
<apritzel>
it gets quite messy, because every SoC seems to be special in some regard
<megi>
thanks :)
<apritzel>
so if I get ~20MB/s on every SoC, having DMA sounds less tempting
<megi>
anyway, for whatever reason my Orange Pi 3's U-Boot runs at 23MiB/s
<apritzel>
but lower than there might be a good reason
<apritzel>
megi: yeah, I will double that again
<apritzel>
I am juggling boards and patches here like crazy, I might have messed something up
<megi>
tell me :)
<apritzel>
and the H616 eMMC is unreliable, I can read max. 6 sectors at the default settings
<apritzel>
though halving the clock seems to fix that
<apritzel>
so there might be more peculiarities with the H616 ...
<apritzel>
(or probably just me being stupid somewhere)
<apritzel>
megi: you mentioned the kernel clock driver has it wrong as well, can you say where (which SoC)?
<apritzel>
megi: because I figured that the kernel is right, and I have little to no problems in Linux
<apritzel>
I think clock doubling/halving can be easily detected by looking at the transfer speed
<apritzel>
for instance I hacked in the clock doubling into the H5 MMC clocks, and it was wrong, the SD card speed was too fast for HS/4bit@50MHz
<megi>
clock doubling is offset by the internal divider in the mmc block, so it works in the end
<tuxd3v>
I compiled mesa lima '21.0.3' for 'minsize', and the difference is night and day, the cursor can now moove a lot faster, but it still flicker a bit..
<tuxd3v>
also in glxgears at each second there are a small freeze of the gears on the screen then it resumes fast.. around 59fps
<anarsoul>
tuxd3v: cursor flickers because there's no hw cursor support in sun4i-drm
<anarsoul>
it's not a lima issue
<tuxd3v>
ho, its possible to implement it or by design it doesn't have it?
<tuxd3v>
anarsoul, why do you think that at each second that passes(its aligned with the seconds..), the gears stop, and rapidly they return there work..
<tuxd3v>
like frames dropped at each second..
<anarsoul>
tuxd3v: there's no dedicated cursor plane. sun4i-drm exposes all available planes, but since none is marked as cursor x11 doesn't attempt to use them
<anarsoul>
megi had some patches to mark one of planes as cursor but I don't remember where they are, maybe he can share a link
<anarsoul>
as for frame drops - no idea, check top output, maybe some process activates once a second to do something
<apritzel>
pnill: I think I see what you mean: setting dr_mode to peripheral doesn't really work as expected: the PHY gets routed to the HCI, not to the MUSB
<pnill>
apritzel: on an H6 device?
<pnill>
and I'm guessing PHY would've been the larger ports.. not the OTG port?
<apritzel>
pnill: I guess everywhere, this in on a Pine64-LTS (A64, but very similar USB situation)
<tuxd3v>
anarsoul, many thanks, that could be well the case with some processes :)
<apritzel>
on both A64 and H6 the port 0 pins are shared between an EHCI host controller and the MUSB, and the mux switch needs to be setup properly
<apritzel>
the Allwinner USB PHY code does that, but the upper layers always ask for host
<tuxd3v>
But clearly there are a huge diference between building it --buildtype 'plain' or --bluidtype 'minsize', minsize is the best option :)
<apritzel>
pnill: I see the dr_mode property being initially recognised as peripheral, but still the USB core asks for host mode, and the PHY driver happily sets that up
<pnill>
so, I don't know if that's what was happening to me but I was able to set it up
<pnill>
setup the configfs
<pnill>
got no errors, it said it set it all up
<pnill>
then it wouldn't work/show anything
<pnill>
even with dr_mode in peripheral instead of otg
<apritzel>
yes, exactly the same I am seeing now
<apritzel>
configfs setup works apparently, but nothing on the host
<apritzel>
which is understandable because the pins are routed to the HCI
<apritzel>
pnill: you could try to replicate the sun50i-h5-orangepi-pc2.dts setup, it was working there for me
<apritzel>
the logic in sun4i_usb_phy0_get_id_det() looks correct to me, but somehow the MUSB core (or some other code) seems to explicitly ask for host mode - and gets it