<minute>
narmstrong: i still used the last patchset from friday which we modified here
<narmstrong>
minute: ok, could you try to rebase to this branch ? I tried to mimic your changes (except the GP0 PLL min div), and I tried to fix the hsync/vsync code like vendor does
<minute>
narmstrong: yes, will do it today!
<minute>
narmstrong: btw there is one other bit that the state_change thing was affecting but i didn't try it
<narmstrong>
minute: yep I saw it, but the dsi bridge missed proper BIT_PHY_STOP_WAIT_TIME calculation, and it doesn't seem to affect anybody so far...
<minute>
ok
<minute>
i did have some glitches (losing sync for 1 frame perhaps?) on the display maybe when there was sd card activity (need to double check), but could also have been EMI
<narmstrong>
the driver definitely needs fine tuning
<minute>
on imx these glitches are usually buffer underruns in the display engine, but don't wanna jump to conclusions
<minute>
but i tried sway with debian bookworm and chromium, going to youtube, tried minetest, and it was all pleasantly fast
<narmstrong>
pretty cool :-)
<narmstrong>
I always dreamed to have A311D on a laptop platform... thx for having this CM4 interposer board!
<minute>
yeah, i plan to put it in my personal device for dogfooding
ldevulder has quit [Quit: Leaving]
f_ has joined #linux-amlogic
rockosov has quit [Ping timeout: 268 seconds]
rockosov has joined #linux-amlogic
ldevulder has joined #linux-amlogic
f_ has quit [Quit: Lost terminal]
naoki has quit [Quit: naoki]
dlan has quit [Ping timeout: 256 seconds]
dlan has joined #linux-amlogic
dlan has quit [Ping timeout: 256 seconds]
dlan has joined #linux-amlogic
camus has quit [Ping timeout: 240 seconds]
<minute>
narmstrong: testing mipi-dsi together with nvme i get distortion on the panel while nvme is accessed, pretty sure these are display buffer underruns or bus contention
<minute>
disk read rate 413.4MB/s, write rate 382MB/s (tested with gnome-disks)
<narmstrong>
minute: it's a known issue, please use the pci=pcie_bus_perf kernel cndline option
<narmstrong>
some people tried to have an in-kernel solution, but none were acceptable
<minute>
oh!
<narmstrong>
the reason of that: the MRRS is left to 512 in the NVMe device while the host only supports 256, so every access actually overflows the AXI bus and leads to underflows in the display, setting the MRRS to 256 solves that
<minute>
wow ok
<minute>
i'm glad you already figured this out :D
<phh>
narmstrong: so linux properly set dram controller's priorities, but nvme still manage to overload the dram busby doing access of lengths longer than anticipated?
<minute>
narmstrong: indeed, this fixes the problem! thanks!!
<narmstrong>
phh: yep, this is because the controller will split the access in a way it overflows the bus
<narmstrong>
phh: I found the explanation in the dw-pcie databook, but it's not easy to summarize...
<phh>
ngl it sounds very painful to find out :P i'm surprised that would be pci-e-side, it's rather a property of dram controller i think?
<narmstrong>
phh: not really, it's really a pcie controller setting, on how it translates PCIe packets into AXI transactions, and Amlogic did set quite a low value (256) while usually 512 is used for NVMe devices
<narmstrong>
but hey it wasn't designed to run NVMe, but only wifi
<phh>
yes but the bus arbitrator (which should be DMC in this case, which i translate to dram controller, but I could be wrong) should pause PCIe's request to give priority to compositor
<narmstrong>
but we, hardcore linux hackers, use it for anything including PCIe switches and full-size PCIe cards :-p
<narmstrong>
phh: I don't know the details, but probably yes, but it's not specific to Amlogic, it happens on the iMX SoCs aswell
<f_>
Which is strange..plat_get_image_source doesn't seem to fail, at all.
<f_>
So I'm stuck...
ldevulder has quit [Quit: Leaving]
<f_>
Might be the very faulty RAM init
<f_>
narmstrong: And you were right, there's no need for a custom wr_reg/rd_reg macro when I could just use mmio_write_32 and mmio_read_32 respectively.
<f_>
(IIRC it was made for this kind of stuff, right?..
<f_>
)
<narmstrong>
Yep sound right
<narmstrong>
f_: not sure why it should use ddr at this point, fip loading would but not table parsing would be from dram
<f_>
¯\_(ツ)_/¯
<f_>
So table parsing doesn't need DRAM.
<f_>
And you mentionned before that BL1 should already load the FIP table along with BL2.
<f_>
At this point let's disable DDR init and see what happens (curious)
<narmstrong>
Yep the memmap driver simply reads the file in memory
<f_>
Yeah I knew it had something to do with RAM.
<f_>
At some point I (or someone else) should really do a better job than Amlogic on RAM init/me on porting.
<f_>
"Anyone would want to rewrite Amlogic's DDR init code???" *everyone steps backwards*
<f_>
But yeah, no change if I disable DDR init.
<f_>
Doesn't seem to work anyway.
<f_>
(it pretends that it has 5GB of RAM.....)
<narmstrong>
Try to grep registers names on Google, pretty sure they use a synopsys ddr controller like plenty of other vendors
<f_>
Good idea!
<narmstrong>
You can try to follow the calls and add print in every function that should be called… it’s poor man’s tracing
vagrantc has joined #linux-amlogic
<f_>
I do have a copy of the S905 datasheet, too. It maybe has information about DRAM, too?
<f_>
Nothing about Synopsys.
<f_>
(in the datasheet)
<f_>
But the datasheet seems to have a list of registers..
<minute>
hmm, with mainline 6.4 (git) i have constant up/down cycling of meson8b-dwmac
<minute>
i.e. link is down, link is up
<minute>
ethernet activity led is oscillating then at high speed
<xdarklight>
minute: on which board are you observing that?
<minute>
xdarklight: bananapi cm4 with a311d
<minute>
ethernet worked with the armbian kernel, checking what they are patching
<xdarklight>
minute: please find the Ethernet PHY reset GPIO in the schematics and configure it like it's done in meson-sm1-x96-air-gbit.dts (see external_phy node)
<minute>
xdarklight: will do, thanks
<minute>
this is normal? > meson8b-dwmac ff3f0000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed
<xdarklight>
definitely not but it points to a PHY issue (I never understood how DMA and PHY are linked, but there's some relation)
<minute>
ok
<xdarklight>
I mean there's other reasons for DMA errors, but them being related to the PHY is my experience
<minute>
that board also has > rx-internal-delay-ps
<xdarklight>
yes, it's an odd board because part of the RGMII delay is added by the PCB trace length and the remainder has to be added by either MAC or PHY. the PHY cannot generate that odd number delay so we let the MAC do it
<minute>
alright
<xdarklight>
*assuming* the CM4 needs a standard 2ns delay then it's current setup is correct (rgmii-id, meaning: the PHY adds 2ns delay in both RX and TX directions)
<minute>
ah, appears to be the same GPIO
<xdarklight>
no wait, CM4 has rgmii-txid
<xdarklight>
try the GPIO first, then change rgmii-txid to rgmii-id
<minute>
alright, interesting
<minute>
ok, so the gpio didn't fix it
<xdarklight>
once we have a fix it would be great if you could still submit the reset GPIO (as a separate patch of course)
<minute>
changing to rgmii-id also didn't change the behavior. hm hm
<xdarklight>
can you dump the PRG_ETH0 register (0xff634540) on the vendor kernel please?
<minute>
i made some progress by changing to phy-mode = "rgmii"; and amlogic,tx-delay-ns = <2>; now it works at 100mbit
<minute>
it does not work at 1000mbit but also the link stays up then
<minute>
i need to check which of those changes made the difference
<xdarklight>
can you please pastebin /sys/kernel/debug/clk/clk_summary ?