Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
radxanaoki has joined #linux-sunxi
radxanaoki has quit []
radxanaoki has joined #linux-sunxi
<loki666>
apritzel: no, we don't have any glue code for panfrost
radxanaoki has quit [Quit: radxanaoki]
radxanaoki has joined #linux-sunxi
apritzel has joined #linux-sunxi
<loki666>
On a different topic, I'll probably get a A527 device
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
cnxsoft has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
Robot_ has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
bauen1 has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
ungeskriptet has joined #linux-sunxi
ungeskriptet_ has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
tokyovigilante_ has quit [Remote host closed the connection]
tokyovigilante has joined #linux-sunxi
<tokyovigilante>
Have a H700 device with 4GB of RAM, and although DRAM detection for u-boot is working well, I'm getting this in when trying to start the display:
<tokyovigilante>
[ 6.511968] [drm] Initialized sun4i-drm 1.0.0 for display-engine on minor 1
<tokyovigilante>
I know there was an issue with the IOMMU only being 32 bit and so having an issue above 4GB, but was a solution ever found?
evgeny_boger has joined #linux-sunxi
radxanaoki1 has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<kuba2k2>
apritzel: I wouldn't even know where to start, I'm not a Linux developer and have never sent any patches to the upstream
radxanaoki has quit [Ping timeout: 480 seconds]
<kuba2k2>
and also I don't know if adding the phys = <&dhpy>; line is the "right" way to do it. But yes, it would be nice to at least try to upstream this
apritzel has joined #linux-sunxi
radxanaoki1 has quit [Remote host closed the connection]
kuba2k2_ has joined #linux-sunxi
kuba2k29 has joined #linux-sunxi
kuba2k2_ has left #linux-sunxi [#linux-sunxi]
<loki666>
tokyovigilante: I think the conclusion, was that nobody will make a board with H700 and 4Gb mem... It's just a configuration not supported
cnxsoft has quit []
kuba2k29 has quit []
cnxsoft has joined #linux-sunxi
kuba2k29 has joined #linux-sunxi
kuba2k29 has quit []
<apritzel>
kuba2k2: this question could be discussed and answered on the mailing list ;-)
<apritzel>
kuba2k2: and for a start: can you add a line saying: "Signed-off-by: Your Name <your@email.com>" to the patch? This would allow someone else to take this patch and upstream it
<apritzel>
also ideally add some lines to say what this patch does, roughly, and why we need that?
<apritzel>
loki666: that's not a good answer ;-) For a start: there are a lot of 4GB boards with the H616 and H618 out there
<apritzel>
it would be good to chase down where the "high request" came from. Don't we mark the de2 device as DMA32 (which would be the default, I think)?
kuba2k24 has quit [Remote host closed the connection]
<tokyovigilante>
apritzel: thanks, would be good to have support for 4GB boards if it’s technically possible, seeing as I have one now :)
<tokyovigilante>
I assume it’s coming from somewhere in the display pipeline but will have to dig into it a bit. disabling the IOMMU for the mixer does allow the system to work fine with 4GB otherwise
<apritzel>
tokyovigilante: in general Linux tends to not impose those restrictions, unless there is a hard technical reason for that
<tokyovigilante>
thanks for the GPU patch too, will try and review/test over the weekend as well as respond to the comments from jernej.
psydroid has quit [Remote host closed the connection]
psydroid has joined #linux-sunxi
kuba2k2 has quit [Quit: kuba2k2]
kuba2k24 has quit []
kuba2k2 has joined #linux-sunxi
<loki666>
apritzel: for the GPU power domain, can't we just flag it as ALWAYS_ON ?
<apritzel>
loki666: for now, as I hack^Wworkaround, I guess?
<apritzel>
but I doubt this will find many friends upstream ...
<loki666>
Arf
<loki666>
Issue seems similar to what the mmc-power-seq try to solve ?
<loki666>
But here panfrost is also playing with the clock and reset
<loki666>
Just probably not in the correct sequence
<apritzel>
well, that's the big question mark. I see some SoCs (MTK) also using clocks, resets, power-domain, for their Malis, so why is it not a problem for them
<loki666>
So they also have a power domain dedicated?
<apritzel>
ah, maybe not dedicated, so it never turns off, good point, but I haven't checked
<apritzel>
what was the sequence of the BSP driver?
<loki666>
ungate, deassert reset, prepare enable clk for power on
<loki666>
And disable clk, assert reset then gate for power off
<wens>
IIRC MTK doesn't expose many reset controls
<jernej>
apritzel: call to of_dma_configure() reconfigures dma
<jernej>
but I would much rather fix iommu driver instead, using bsp driver trick
JohnDoe_71Rus has joined #linux-sunxi
<jernej>
idea is that iommu will never handle memory in the range of 0 - 0x40000000 since it is peripheral memory range, so if you get such address, you simply add 0x100000000. For storing such address is even simpler - you just ignore bit 32.
<apritzel>
loki666: right, so it seems Panfrost does it exactly the other way around? I see panfrost_clk_init(), panfrost_reset_init(), panfrost_pm_domain_init()?
<apritzel>
jernej: mmh, sounds a bit sketchy, though. Authentic AW, I'd say ;-) Does the translation hardware know about this trick? Or is the IOMMU address range relative to beginning DRAM anyway?
<jernej>
I think iommu must know this trick internally, otherwise it wouldn't work?
<jernej>
I have no idea about internal working
<apritzel>
lol, me neither, don't really know how the driver works, tbh
<jernej>
well, I know pretty well how driver works since I spend quite some time fixing it, but details like this bit 32 are not described, I think. Let me check.
cnxsoft has quit [Ping timeout: 480 seconds]
<jernej>
but I would take this chance to test this theory since tokyovigilante can test this his setup
<jernej>
*on his setup pretty well
<apritzel>
yeah, I would need to patch in the HDMI support to test this, which still contains hacky patches, IIRC?
<jernej>
H616? yeah, I'll post my comments on that series today
<apritzel>
jernej: were there any HDMI patches on the list already? Or do your refer to the DE33 series?
tlwoerner has joined #linux-sunxi
<jernej>
oh, DE33 series. HDMI patches are on my gh
<apritzel>
jernej: so from just grep'ing around in some T527 BSP IOMMU driver, it suggests that bits[9:8] of the PTE contain bits[33:32], but this isn't mentioned in the manual?
<apritzel>
in which case it wouldn't be some "trick", but some undocumented h/w feature, similar to what other AW devices already use ("find one or two unused bits somewhere and (ab)use them for bits[33:32]")
<jernej>
apritzel: it's not documented, check 2.11.3.3 VA-PA Mapping in T527 manual
<jernej>
apritzel: but that doesn't help us with H616, which for sure doesn't have that
<apritzel>
so A523/T527 is v2, but H616 is V1, as per the BSP naming?
<jernej>
I have no idea what v2 and v3 are, but v1 driver from A523 BSP contains compatible for both, H616 and A523
<kuba2k2>
apritzel: I think I got the patches, but who should I send them to? I assume every email from "DRM DRIVERS FOR ALLWINNER A10" and "ARM/Allwinner sunXi SoC support"?
<kuba2k2>
that's what scripts/get_maintainer.pl shows, at least
<apritzel>
kuba2k2: yes!
<kuba2k2>
should I include the DT binding maintainers too? (and RISC-V..? it's not really specific to RISC-V at all)
<jernej>
kuba2k2: if not sure, include all maintainers, reviewers and mailing lists listed by that command.
<kuba2k2>
okay, got it
<apritzel>
jernej: so the other way (phys address to PTE value) is automatic, because it gets truncated to 32-bit?
<palmer>
ya, I generally just include everyone
<jernej>
apritzel: yes
<kuba2k2>
ok I sent the patches, but the messages couldn't get delivered to Maxime Ripard and Samuel Holland for some reason...
<loki666>
apritzel: px30 seems to have a dedicated gpu power domain
<loki666>
and the GPU clk is also referenced from the power domain
<loki666>
same for rk3576
<apritzel>
loki666: so do you have a setup that shows the problem immediately? How does it behave? Does it hang, does it crash? And that happens when, exactly? When the power domains gets enabled the second time?
<loki666>
building image
<loki666>
I'll probably need to add logs
Robot_ has quit [Ping timeout: 480 seconds]
<loki666>
unfortunately, I won't have time to do much... I'll be AFK until next sunday