<apritzel>
gediz0x539: so thanks, that's interesting. The sample size is just 3 for now (Pinebook, Pine64-LTS, your board), but it seems like it's more a board than a SoC limit then
<apritzel>
which means the fixes should go to the .dts files, not the .dtsi
<mripard>
gediz0x539: if you change the max-frequency property to 150MHz, do you have see any impact on the perf?
<gediz0x539>
apritzel: agree, it probably depends on the board. eMMC bus on my board is designed carefully to make it work for a proper high speed bus. so i think it'd have helped. eMMC supports HS400 too, i wish A64 supported that.
<gediz0x539>
mripard: let me try
daregap has quit [Quit: daregap]
<apritzel>
gediz0x539: the A64 does support HS400, just the driver does not
<gediz0x539>
apritzel: what about that 150MHz limit?
<apritzel>
but the benefit would be questionable, given that most chips rarely deliver close to 200MB/s anyway
kaspter has quit [Quit: kaspter]
<gediz0x539>
hrm
<apritzel>
gediz0x539: what's the size of your chip? that has an impact on the transfer rate as well
faruk has joined #linux-sunxi
<gediz0x539>
8GB. namely, SDINBDG4-8G
jelly-home has quit [Ping timeout: 264 seconds]
<apritzel>
gediz0x539: thanks. so on those there does not seem to be a read limit, even on the 8GB version
<faruk>
mripard: Hi, we work together with gediz0x539. Changing it to 150MHz did not change much. There is the result https://hastebin.com/ukafexagan.yaml
<apritzel>
but I have seen those limits on 8GB Samsung eMMCs (probably cheaper consumer grade versions)
<mripard>
faruk: thanks
<mripard>
so it's roughly a 3-4% difference
<faruk>
mripard: you're welcome.
<gediz0x539>
apritzel: yw, thank you too. i will try with a larger one soon. it'd probably change the write performance, as you said.
dddddd has quit [Ping timeout: 256 seconds]
<apritzel>
gediz0x539: yes, according to the Sandisk datasheet it's 40MB/s for 8GB, 80MB/s for 16 and 160MB/s beyond that, bit less for HS200
jelly-home has joined #linux-sunxi
<apritzel>
btw, for the non-pro Samsung eMMCs (as used on the BPI-M64) it's 100 MB/s read and 6(!) MB/s write only
dddddd has joined #linux-sunxi
<apritzel>
(for the 8GB version)
<gediz0x539>
100 MB/s read is cool but 6 MB/s write is meh :/
<gediz0x539>
like and off-the-self SD card
<gediz0x539>
s/and/an/
<apritzel>
gediz0x539: 100 MB/s is not bad, but that's the datasheet value, reality might spoil this
<gediz0x539>
s/self/shelf/ lol i cannot even write today
<gediz0x539>
apritzel: yes there're actually ton of different parameters
<apritzel>
and it's 180MB/s read for the 8GB Pro version, and 170MB/s for the 16GB non-Pro version
<apritzel>
so it's really a limit of the cheapest option only
<apritzel>
100MB/s is probably downhill, dry road, full sunshine ;-)
<gediz0x539>
marketing ppl work well
Net147 has quit [Read error: Connection reset by peer]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
akaWolf has quit [Ping timeout: 265 seconds]
<gediz0x539>
apritzel: is HS400 mode supported in BSP kernel of A64?
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
<gediz0x539>
im just embarrassed that how i do not know about A64 supporting HS400. i will check bsp to see if it's supported there. maybe i can try to port it to mainline.
<apritzel>
gediz0x539: looks like, but I don't go there for just HS400
<apritzel>
gediz0x539: it involves setting up specific clock delay values, AFAIK
<gediz0x539>
apritzel: agree. it wouldn't worth the hassle/pain to switch back to 3.10 only for the sake of faster eMMC. just to check if it actually works, or as a reference codebase maybe.
<gediz0x539>
apritzel: okay then. i will look. thanks.
<apritzel>
gediz0x539: that's what I meant: I wouldn't ever bother to *look* at the code ;-)
<gediz0x539>
oh lol
<apritzel>
I think there are some hints that HS400 is also frequency limited
<apritzel>
so the win over HS200 is probably marginal, and might even be theoretical given the typical eMMC chip performance
<gediz0x539>
if i had known about driver development as much as you, i'd not touch that poison too :) i just have no idea about how an eMMC driver works
<gediz0x539>
i see. so it sounds better to stay at HS200 for now
<apritzel>
gediz0x539: if I were you, I would try to run some I/O stress tests, to see if the 200 MHz HS200 are reliable
<apritzel>
and then back of to 150 MHz anyway
<apritzel>
(good old engineering rule)
<gediz0x539>
thanks for the tip. i will definitely do that.
<apritzel>
MoeIcenowy: do you have any further information about the PortF voltage switch on the H616/V831? I tried that bit in +0x350, also various "withstand" registers, but it didn't work, I measure ~0.3V instead
faruk has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-sunxi
akaWolf has joined #linux-sunxi
lurchi__ is now known as lurchi_
akaWolf has quit [Ping timeout: 260 seconds]
reinforce has quit [Quit: Leaving.]
lurchi_ is now known as lurchi__
<asdf28>
does using libUMP with the mali graphics driver have any performance benefit?
cmeerw has joined #linux-sunxi
<asdf28>
do newer drivers actually use this?
lurchi__ has quit [Ping timeout: 256 seconds]
<asdf28>
is the openGL driver (libMali.so) hardwired to use libUMP?
akaWolf has joined #linux-sunxi
diego71 has quit [Ping timeout: 246 seconds]
sunshavi_ has quit [Quit: WeeChat 2.9]
popolon has joined #linux-sunxi
sunshavi has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
sunshavi has quit [Quit: WeeChat 2.9]
sunshavi has joined #linux-sunxi
diego71 has joined #linux-sunxi
victhor has joined #linux-sunxi
vagrantc has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
<MoeIcenowy>
apritzel: nothing
<MoeIcenowy>
maybe H6 do not have VCC18-IO connected
<apritzel>
MoeIcenowy: so from what I read in the manual, this bit in +0x350 switches the PortF supply from VCC-IO to VCC-PLL
<apritzel>
where the first is almost always 3.3V, and VCC-PLL is always 1.8V
<MoeIcenowy>
apritzel: on V831 there's a VCC18-IO
<MoeIcenowy>
which might got omitted on H616
<apritzel>
I see, the H616 datasheet says for PortF "VCC_IO,or VCC_PLL"
<MoeIcenowy>
oh?
<apritzel>
which should be equivalent, only that VCC-PLL is required for operation and must always be 1.8V
<apritzel>
so nothing a board vendor could forget ;-)
<apritzel>
found some hint about a VCC-PLL regulator in the RTC, maybe one has to flip some bit in there first ...
<apritzel>
ha, I think I got it: I turned every pin off first (func7), then set bit 12 in +0x340, then turned the pins back on
<apritzel>
(plus clearing bit 0 in +0x350)
<apritzel>
will check UHS-I later tonight again, but I measure 1.76V on a PF pin now
<apritzel>
(this sequence complicates the driver code, since we have to ask pinctrl to disable the pins first ...)
_0x5eb_ has quit [Quit: Goodbye!]
* willmore
claps for apritzel
zoobab has quit [Ping timeout: 264 seconds]
<willmore>
And, to be clear, this would us to run UHS-1 speed on *one* pin of the Opi zero 2?
<apritzel>
UHS-I requires a 4-bit bus (at least according to the spec)
<apritzel>
this would allow UHS-I on probably any H616 boards in the normal first SD slot
<apritzel>
using UHS-I on the second and third controller would already be possible on other SoCs
<apritzel>
as long as you can *switch* the voltage for PortG or PortC
<apritzel>
eMMC can start on 1.8V already, so just a constant 1.8V supply is good, but SD cards need to start at 3.3V, and then switch to 1.8V
gaston1980 has joined #linux-sunxi
<apritzel>
(at least this is my understanding)
zoobab has joined #linux-sunxi
<MoeIcenowy>
BTW many SDIO Wi-Fi can also work on fixed 1.8
<willmore>
Okay, so this will let H616 board run their primary uSD slot at UHS-1? That's useful in and of itself. Since the other ports aren't easily converted to 1.8V and no one has put bidirectional buffers on them with selectable voltage, I guess it's not likely to be used much there.
<willmore>
MoeIcenowy, good to know!
<apritzel>
MoeIcenowy: yeah, didn't check the SDIO part specifically, but it's probably true
* apritzel
is eyeing the PineA64 WiFi slot, to connect an SD card there ...
<MoeIcenowy>
apritzel: at least on some boards, PortG is locked at 1.8
<MoeIcenowy>
(by board design
<MoeIcenowy>
e.g. Pine A64-LTS, it connected VCC-PG to ELDO1, and then ELDO1 to VCC18-LPDDR
<willmore>
FWIW: ST6G3244ME and T3GF3WBG are buffer/translator chips made specifically for UHS-1 3.3 to 1.8V translation.
<willmore>
Board makers ^^^^^
<apritzel>
MoeIcenowy: yeah, possibly, didn't check the details yet ...
<willmore>
Hmm, these buffer chips always expect the host to be fixed at 1.8V.
tnovotny has quit [Quit: Leaving]
<apritzel>
willmore: that would not be helpful on the older SoCs, and we wouldn't need those chips on the newer SoCs (H616 and friends)
<apritzel>
we want constant 3.3V on the host side, and select between 3.3 and 1.8 on the card side
<apritzel>
sounds like us mere mortals could build something with some FETs already ...
<apritzel>
MoeIcenowy: yeah, you are right, even on the original Pine64 we are stuck to 1.8V on PortG because of CPVDD
apritzel has quit [Ping timeout: 246 seconds]
juri_ has quit [Ping timeout: 258 seconds]
ldevulder has quit [Quit: Leaving]
juri_ has joined #linux-sunxi
<willmore>
I'm looking for ones with 3.3v on the host side.
<willmore>
Then it seems the Pine64 would benefit from one of these chips if you want to interface to a uSD card at UHS-1 speeds. I wonder if there's a direction signal on the standard eMMC connector. One could make an eMMC board that has a uSD slot on it that could host a UHS-1 card.
jelly-home is now known as jelly
gaston1980 has quit [Quit: Konversation terminated!]
apritzel has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
xzz53 has joined #linux-sunxi
black_ink has joined #linux-sunxi
night199uk has quit [Ping timeout: 268 seconds]
night199uk has joined #linux-sunxi
asdf28 has quit [Ping timeout: 260 seconds]
Net147 has quit [Ping timeout: 268 seconds]
Net147 has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
andy25225 has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
Hauke has quit [Quit: WeeChat 2.3]
jstein has joined #linux-sunxi
andy25225_ has joined #linux-sunxi
andy25225_ has quit [Remote host closed the connection]
lurchi__ has joined #linux-sunxi
zoobab has quit [Ping timeout: 256 seconds]
zoobab has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 256 seconds]
lurchi__ has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 264 seconds]
cmeerw has quit [Ping timeout: 258 seconds]
lurchi__ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]