<gnarface>
there looks like other stuff in here i think is non-default and probably important for making lima work
<gnarface>
but i can't claim to have tested this, i just saved it because it looked promising
<gnarface>
you may want to also consider checking and setting DRI1 or DRI2
<gnarface>
or DRI3?
<gnarface>
again, haven't tested this on pine64 hardware, but i've observed on some Intel integrated video devices you have to force either DRI2 or DRI3 because in certain cases it picks the wrong one
<tuxd3v>
DRI3 :)
buzzmarshall has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
<anarsoul>
gnarface: you can't disable AIGLX without loosing GLX :)
elros1 has quit [Read error: Connection reset by peer]
xes has quit [Ping timeout: 240 seconds]
Mangy_Dog has joined #linux-sunxi
elros1 has joined #linux-sunxi
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
mossroy has joined #linux-sunxi
jstefanop has joined #linux-sunxi
choozy has joined #linux-sunxi
jstefanop has quit [Ping timeout: 268 seconds]
mossroy has quit [Remote host closed the connection]
x5eb has joined #linux-sunxi
_0x5eb_ has quit [Ping timeout: 260 seconds]
_0x5eb_- has joined #linux-sunxi
x5eb is now known as _0x5eb_
_0x5eb_- has quit [Client Quit]
x5eb has joined #linux-sunxi
<tuxd3v>
anarsoul, many thanks for that info seems that I need to wait and see if its backported :)
<tuxd3v>
in the meantime glxgeras was able to achieve 330fps, last compilation during the night yelded a 5-10% increase in performance :)
<tuxd3v>
ho.. without vblank
<tuxd3v>
mali400
akaWolf has quit [Ping timeout: 268 seconds]
tnovotny has quit [Quit: Leaving]
sunshavi has quit [Ping timeout: 252 seconds]
lucascastro has joined #linux-sunxi
sunshavi has joined #linux-sunxi
jstefanop has joined #linux-sunxi
cmeerw has joined #linux-sunxi
yann has quit [Ping timeout: 260 seconds]
Mangy_Dog has quit [Remote host closed the connection]
matthias_bgg has quit [Quit: Leaving]
_0x5eb_ has quit [Quit: Goodbye!]
x5eb is now known as _0x5eb_
elros1 has quit [Remote host closed the connection]
Mangy_Dog has joined #linux-sunxi
lucas_ has joined #linux-sunxi
lucascastro has quit [Read error: Connection reset by peer]
dev1990_ has quit [Excess Flood]
dev1990_ has joined #linux-sunxi
aballier_ has quit [Ping timeout: 252 seconds]
aballier has joined #linux-sunxi
ldevulder has quit [Remote host closed the connection]
<apritzel>
megi: I think I was somewhat dense, I now eventually get what you were saying about the H5 MMC clock: The x2 PLL source and the /2 postdiv cancel each other out
<apritzel>
megi: which was probably Allwinner's idea in the first place: to keep the clock effectively the same
<apritzel>
megi: but to allow a 400 MHz setting for HS400 (which I think would be 200 MHz clock, doubled by being DDR), a 600 MHz parent doesn't cut it
<jernej>
apritzel: in summary, how much is there to fix in U-Boot and Linux regarding mmc clocks?
<apritzel>
jernej: depends on how fast you want to go ;-)
<apritzel>
I think a lot of stuff just fits "by chance"
<megi>
:)
<jernej>
DDR50 actually bothers me, because it doesn't work on some boards
<jernej>
but it should
<apritzel>
I have the DDR50 support isolated, that's very reasonable
<apritzel>
it seems to work on the Pine64-LTS, but doesn't improve the transfer rate, because that's limited by MMIO
<megi>
I tested DMA patches on quite a lot of SoCs
<apritzel>
jernej: do you mean in Linux? I saw some issues lately as well: HS200 works on the Pine64-LTS, but DDR50 does not
<megi>
H3, H5, H6, A83T, A64, mostly newer ones though
yann has joined #linux-sunxi
<apritzel>
megi: I believe that, still I feel somewhat uncomfortable with that change
<jernej>
apritzel: both, actually - it doesn't help if only one works but not the other
<megi>
so it should work quite well, if you pick it up too
<apritzel>
megi: mostly because it adds complexity
<megi>
right
<apritzel>
jernej: well, as I said: without DMA we don't need to bother with DDR50 in U-Boot, so we could keep it to SDR50
<apritzel>
jernej: if any of the "advanced" modes causes trouble, I'd rather have 20 MB/s in U-Boot, but stable
<jernej>
sure, me too
<apritzel>
jernej: but I am still not finished with my MMC investigations, the MMC issue on the H616 is still unsolved
<apritzel>
only in U-Boot, though, which makes me hopeful that I can find something by comparing registers
<jernej>
that address shift is relevant only for DMA access?
<apritzel>
jernej: yes
<apritzel>
also the 13bit DMA limit for MMC2 on A64 & later
<apritzel>
which was the reason that we didn'
<apritzel>
didn't need to differentiate between the SoCs
<apritzel>
it's not a big problem, but the fact that we need MMC in the SPL doesn't simplify things
<jernej>
you could abuse bootrom for MMC in SPL :)
<jernej>
maybe
<megi>
hmm?
akaWolf has joined #linux-sunxi
<megi>
call into bootrom functions? :)
<jernej>
yes :)
hlauer has joined #linux-sunxi
<jernej>
I can't remember where I heard that, maybe for some Rockchip SoC
<jernej>
but that would mean running SPL in 32-bit mode
<megi>
not sure about bootrom revisions
<megi>
are there multiple revisions on the same SoC over time?
<jernej>
I don't know
<jernej>
it's safer to reimplement it
<apritzel>
jernej: I am not sure we need less slower, more complicated, unsafer and unfixable ;-)
<apritzel>
(referring to using the BROM)
<megi>
:D
ldevulder has joined #linux-sunxi
eduardas has quit [Quit: Konversation terminated!]
cmeerw has quit [Ping timeout: 250 seconds]
cmeerw has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 240 seconds]
tuxd3v has quit [Read error: Connection reset by peer]
<apritzel>
megi: jernej: hah! 43706880 bytes read in 1007 ms (41.4 MiB/s)
<megi>
:)
<megi>
what mode? :)
<apritzel>
MMC high speed @ 8/bit 52MHz, so out of theoretically 52 MB/s
<apritzel>
without DMA!
<megi>
nice :)
<apritzel>
I figured we read one word from the FIFO, then read the status register, then read the next word ...
<apritzel>
but the status register actually has a count of available words
pnill has quit [Read error: Connection reset by peer]
<megi>
great!
pnill has joined #linux-sunxi
<apritzel>
so I now read the status register, then read <n> words in a tight loop, then check the status again
<apritzel>
now I will pull in your DDR enable patch and see what it does
<apritzel>
for the clock doubling: I figured that's not really useful, so I just always read the base rate of PLL6, and use that
<apritzel>
for the new timing modes, that's only half of the actual rate, but we never consider the postdiv anyway, so that cancels out
<megi>
btw, while playing with this I accidentally doubled the SD card clock and it still worked, just at twice the speed :)
<apritzel>
yeah, I saw this before
<apritzel>
in Linux, on the H616
<megi>
the card is made for much faster clocks anyway
<apritzel>
indeed
<megi>
just at slightly lower voltages
<megi>
and different timings
<apritzel>
and there are some indications that some modes can also work on 3.3V
<megi>
but I guess tolerances are not that tight
<apritzel>
indeed, it's effectively overclocking
<megi>
yes
<apritzel>
might be lucky with decent cards
<megi>
kinda tempting to just sacrifice one of my sandisks to see how stable this can be longerterm
<apritzel>
I guess for a particular card it should be fine, just not for those cards you grab at the till in the supermarket or from some random eBay auction
<megi>
yeah, just like with any other overclocking
<apritzel>
btw: the H616 supports switching portF to 1.8V, and I did some experiments on the OPi Zero 2, with the SD voltage switch protocol
<apritzel>
I got somewhere, I saw the card ack'ing the 1.8V request, and measured 1.8V eventually
<apritzel>
but then it didn't work
<apritzel>
the pullups on the CMD line are towards a fixed 3.3V, I just hope that doesn't spoil it
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
jelly has quit [Remote host closed the connection]