<KREYREN_oftc>
Hmm i wonder if the AXP803 can power from USB-C
<KREYREN_oftc>
but probably a bad idea considering that it only can handle 5V
<KREYREN_oftc>
(the current connector on teres is garbage that keeps breaking)
<apritzel>
KREYREN_oftc: sure you can connect a USB-C connector to the PMIC. The other end will never put anything higher than 5V on the cable, unless this is explicitly negotiated
<apritzel>
we see USB-C connectors on most new boards now, and they are just passively wired, so just act as more robust replacement for micro-USB, and are 5V only
<apritzel>
I don't think you get a role switch with that simple method, though, but am not sure about it, there might be tricks. It's definitely not as simple as wiring some ID pin to a GPIO anymore
<apritzel>
but if you just want USB-C for power, that should be no problem
ftg has quit [Read error: Connection reset by peer]
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
apritzel, i was thinking USB-C for both power and as OTG for interfacing with u-boot e.g. fastboot to access emmc
<Jookia>
i know the axp203 or something cannot supply much power by vbus
<Jookia>
i had to add a diode to my lime2 to support otg power
<Jookia>
but otg as power + data is very much a great thing for development
vagrantc has quit [Quit: leaving]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
apritzel has joined #linux-sunxi
<tokyovigilante>
Posted up a few RG35XX+ pics, including a closeup of the PMIC, looks like it should be possible to figure out where the DCDC3 line goes
<apritzel>
tokyovigilante: ah, thank you, much appreciated!
Schimsalabim_ has joined #linux-sunxi
Schimsalabim_ has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
<apritzel>
KREYREN: if you mean "USB device" when talking about OTG, then this is rather easy with USB-C
<apritzel>
This is what's implemented on many recent boards: they connect CC1 and CC2 to GND via 5.1K resistors, and that tells the other end that this is a UFP
<apritzel>
What's not so easy is a role *switch*, so when you want to use that port as a host port *also*, to connect for instance a USB stick
<apritzel>
tokyovigilante: so staring at the pictures, the datasheet and some random schematic, I'd say the right hand side of the inductor at the top right of the AXP717 should carry the DCDC3 voltage
<apritzel>
the fourth pin from the right on the top side should be LX3 (pin 30), that goes to the inductor's left hand side, and pin FB3 (pin 29, third from the right) connects to the right hand side of the inductor and carries the output
<apritzel>
but please double check that, some example schematic is in section 7.1 of the datasheet, and the pinout is figure 4-1. Match the dot on the actual chip to that circle in the pinout diagram
<apritzel>
did you compile the DTB: "$ make dtbs". And did end up loading this generated DTB? If you are loading through UEFI, then the DTB comes from U-Boot.
<apritzel>
KREYREN: not sure how you boot, exactly, I guess it uses U-Boot's DTB copy? That would be the case if U-Boot picks up EFI/BOOT/bootaa64.efi automatically, and you have no extra boot script
<KREYREN_oftc>
seems to be UEFI without any extra scripts
<KREYREN_oftc>
it seems to make sense, i try to patch the U-Boot and make an issue about this to nixos to account for this scenario, thanks!
<KREYREN_oftc>
oh actually i can add extraMakeFlags
<apritzel>
KREYREN_oftc: you can just apply the patch to the U-Boot source tree, the .dts files in there should be almost identical to the kernel tree, they are just under arch/arm/dts instead of arch/arm64/boot/dts/allwinner
<KREYREN_oftc>
noted
palmer_ has quit []
palmer has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
warpme has quit []
chewitt has joined #linux-sunxi
<KREYREN_oftc>
does it make sense for A64 to unload the LIMA drivers to disable the hardware acceleration to save battery? As it seems to have 2 cards? (maybe something like primus on nvidia?)
<apritzel>
KREYREN_oftc: what "cards" exactly? There is only one GPU (3D accelerator) in the system. Are you talking about two video output ports?
<KREYREN_oftc>
[root@tsvetan:/home/raptor]# ls /sys/class/drm
<KREYREN_oftc>
card0 card0-eDP-1 card1 renderD128 version
<apritzel>
where does card1 link to?
<KREYREN_oftc>
afaiu once is display-engine which seems to be the anx6345 providing the eDP bridge and the other is the MALI GPU
<KREYREN_oftc>
and it seems to provide display with LIMA unloaded
<apritzel>
yes, because Mali is a pure memory-to-memory 3D renderer, it is not directly involved in any video output generation
<KREYREN_oftc>
oh i see
<apritzel>
that is what the Allwinner DisplayEngine (DE) does, and it's totally separate from Mali
<KREYREN_oftc>
hmm would it make sense to adjust the userland profiles to manage when to use the hardware acceleration to preserve battery?
<apritzel>
it should do that already
<KREYREN_oftc>
oh oke
<KREYREN_oftc>
also speaking of battery life.. do you know if there is a way to get a bigger and ideally 2 hot-swappable batteries hooked to the AXP803 ?
<apritzel>
there is no separate voltage rail for the GPU on the A64 (later SoCs have that, though)
<KREYREN_oftc>
i was told by olimex that more than 9000 mAh would cause the chip to blow up.. or at least as far as i understood
<apritzel>
so all there is is the clock gate and the reset line, and ideally the driver should turn them of if not needed
<KREYREN_oftc>
i see
<apritzel>
I have no idea about support for multiple batteries or a capacity limitation, but I'd assume the AXP803 is only designed to care about one battery
<KREYREN_oftc>
apritzel, i was thinking about connecting them in series so that if one battery is removed it would be shown as the system suddenly having half the capacity (assuming both at 100% charge)
<apritzel>
in series? do you mean in parallel? and how do you assume the AXP can detect the capacity change?
<KREYREN_oftc>
oh ye in parallel
<KREYREN_oftc>
wait no in parallel it would have a risk of charging the other battery.. ehh to be addressed assume not an issue atm
<KREYREN_oftc>
hmm about the capacity detection no idea atm it has data pins that i was thinking i could fool with a microcontroller
<apritzel>
I am not an expert in this, but to my understanding the capacity is something that is calculated, based on the battery voltage dropping when discharging, and this being matched to assumed capacity points
<apritzel>
there is no "capacity report protocol" or such from the battery, if you were hoping for this
<KREYREN_oftc>
ye i was hoping that it would be calculating the capacity from voltage/amperage and that if it's only limited to 9000 mAh that i could connect 2 batteries that are managed by a microcontroller that reports the values to the AXP in the worst case
<KREYREN_oftc>
so that for the AXP it would seem like one battery
<apritzel>
charging a Li-Ion battery is tricky, one of the reasons we have the AXP chips. I don't think just wiring two batteries together will work
<KREYREN_oftc>
ye.. was hoping that sunxi has an expert on the subject somewhere bcs tsvetan appeared to be very nervous when i was asking him about it :D
<apritzel>
probably he knows it's tricky and dangerous to play with that, so he has some respect?
<KREYREN_oftc>
probably
* KREYREN_oftc
would ideally want two 49.4Wh batteries so that his teres has a battery life of 2 months considering that it can already do well above 1 week on the 9K mAh
* apritzel
wants a pony
* KREYREN_oftc
was watching an amish documentary with his bf yesterday and can see the appeal of that especially when he keeps getting annoyed by cops for using a car in the city
<apritzel>
you could always hook up a power bank externally, couldn't you?
<KREYREN_oftc>
apritzel, actually! hmmm
<apritzel>
especially since the input voltage is 5V anyways, isn't it?
<KREYREN_oftc>
that's not a bad idea.. i could reduce the battery in teres and then make an independent battery that just provides the charging voltage for AXP803
<KREYREN_oftc>
apritzel, it's 5V and up to 3A i am told
<KREYREN_oftc>
so 15W
<apritzel>
5V has the advantage that you can use off-the-self USB power banks, and don't have to wastefully boost up the voltage, for the laptop to buck that down again
<diego71>
yes, you can find under /sys/class/power/
<diego71>
the default charger of teres is well more than 1A
<diego71>
but the cpu usually use around 800mA even in idle so, charging battery is slow with the 1.5A default
<diego71>
you can change the default in /sys/class/power_supply/axp813-ac/input_current_limit
<diego71>
I set to 2.5A, and it looks like it doesn't reset when poweroff.
<diego71>
KREYREN_oftc: ^
apritzel has joined #linux-sunxi
warpme has quit []
<KREYREN_oftc>
diego71, interesting that's for info
<apritzel>
diego71: ah, thanks, that's exactly the variable that ends up in that AXP register!
<diego71>
I also made a custom cable usb A <-> teres jack, for charging from any usb port
<KREYREN_oftc>
but actually the idea is integrating an independent circuit that provides charging voltage for the internal battery that can be hot-swapped
<KREYREN_oftc>
diego71, ye i have mine in WAGO connectors so that i can charge from anywhere :D
<KREYREN_oftc>
i once charged it from a street lamp
<diego71>
uhm... I like to play safe , no risk of short circuit
<diego71>
or wrong voltage
<KREYREN_oftc>
there ain't such risk it's self-contained
<KREYREN_oftc>
hmm some powerbanks can be charged even with 240VAC though so that might be interesting
jakllsch has quit [Remote host closed the connection]
jakllsch has joined #linux-sunxi
<apritzel>
ity: after some thinking and looking at the A64 user manual, I think I know what the MBUS does:
<apritzel>
it's part of the DRAM controller, and arbitrates and coordinates access from DRAM users to the DRAM
<apritzel>
think the CPU wanting to write some data, the display engine needing the scan out another line from the framebuffer, the Mali GPU wanting to access its texture buffers and the MMC controller writing the content of the sector it just read from the SD card
<apritzel>
so the MBUS part has ports for all of those users, that's what's shown as those blue boxes, in the upper left corner of figure 3-1 "System bus tree" in the A64 manual
<apritzel>
and it uses the priority values programmed by U-Boot to prioritise certain users over others, if need be
<ity>
OOOOH, thank you, that makes so much more sense now!
<apritzel>
once programmed, it does its job without further software interaction, although one *could* think of tweaking those values in Linux, probably using the resctrl framework (which is x86 only atm)
<apritzel>
the reason we have a DT node is mostly to reference its clocks, and to simplify having some driver which can connect to devfreq
<apritzel>
as such this driver is optional, though probably beneficial for power savings
<ity>
Ah, so the DT node is there for being referenced by other drivers + simplifying the devfreq driver?
<apritzel>
well, that's one part, to provide a target for the interconnect property, but also to have some device that references the DRAM clock, so it can be controlled by Linux
<apritzel>
we describe the DRAM clock in our clock driver, but there is no direct user, so we have to mark it as CLK_IS_CRITICAL, to prevent the kernel from turning it off
<ity>
Hmm, which one is the clock driver? Aren't there multiple clock drivers? I am really confused rn haha
<jernej>
apritzel: there is one more thing, ranges property
<jernej>
on some soc, DMA address needs to be shifted for 0x40000000 down in order to work properly
<apritzel>
ah, good point, I was scratching my head what the interconnect property is doing, since I didn't see the driver registering to any interconnect framework
<apritzel>
but I guess this is all handled by generic code then, which chases the interconnect property and observes dma-ranges on the way
<apritzel>
jernej: thanks for pointing this out!
<jernej>
yes, this is done automatically
<apritzel>
so is it because DI is special (as in: broken), and doesn't observe the 1GB DRAM offset like all other DMA users do?
<apritzel>
I mean I am pretty sure we write the physical bus address into the DMA engines of MMC and Ethernet?
<gnarface>
i see you guys are talking about A64 devices here. sorry to barge in on the conversation but do any of you happen to know the trick to make the SDIO port go faster on the "pine64+" A64 boards? so far i've got this patch to make the port work: http://paste.debian.net/1308698/
<gnarface>
i tried adding "sd-uhs-sdr104;" to that to make the port go faster but obviously there's more to it than that, because that doesn't change anything
<Jookia>
gnarface: i think you have to be able to set the voltage lower too
<Jookia>
unless i'm thinking of something else
<jernej>
apritzel: yes
<gnarface>
Jookia: thanks for that tip, i've heard that suggested elsewhere too, but i don't actually know what i'm doing here, so i don't know how
<apritzel>
gnarface: Jookia: yes, going beyond 25MB/s typically means 1.8V, per MMC spec
<apritzel>
gnarface: point is: mostly you can't change the voltage :-(
<Jookia>
do you have schematics for the board?
<apritzel>
you would need to change the voltage of the I/O pins, and both sides need to be ready for that
<gnarface>
apritzel: so the actual answer is that nobody knows how to make this go faster now?
<apritzel>
gnarface: so you want to accelerate the SDIO interface on those 2mm headers on the Pine64?
<apritzel>
I don't even know if SDIO supports faster speed modes, or if there is actually such a thing for SDIO
<apritzel>
for instance to go faster on SD cards, you need to switch the I/O voltage *on the fly* from 3.3V to 1.8V, which only the H616 (and later chips) support
<KREYREN_oftc>
apritzel, is there a way to build only the dts for teres? it's building all of them atm
<Jookia>
schematics say sd card is at 3.3v
<gnarface>
apritzel: multiple sources have told me it's supposed to be able to go to UHS and confirm that i need to use lower voltage but none of them can tell me how or even managed to articulate how they could tell i haven't
<Jookia>
NAND/eMMC goes directly to the chip with no pull-u
<Jookia>
up
<apritzel>
gnarface: are you talking about the SD card?
<gnarface>
apritzel: no, i'm talking about the wifi device that attaches to the SDIO port
<apritzel>
let me check the schematic
<gnarface>
full disclosure, i didn't write this patch
<gnarface>
i merely used basic pattern matching skills to make it build against the debian oldstable kernel i was using at the time
<apritzel>
it's impossible on the SD card, since the voltage is hardwired to 3.3V
<gnarface>
it's adapted from a moicenowy patch
<gnarface>
(i found it on a mailing list archive wherein it was getting refused from the mainline kernel a couple years back now)
<gnarface>
yea, no i don't need the sd card to go faster for this application, just the wifi
<gnarface>
Jookia: thank you, but that's gibberish to me
<gnarface>
like i said, i didn't write this patch, i just used basic pattern matching skills to update it
<gnarface>
as in, strings and css style understanding of { }
<gnarface>
i couldn't tell you what a ®_dldo4 was to save my life
<gnarface>
anyway, would greatly appreciate a literal fix to the patch, explanation also appreciated but optional... not holding my breath for either though.
<apritzel>
so PortG is already on 1.8V, so higher speed modes should work already
<Jookia>
is mmc the same thing as sdio?
<gnarface>
it seems to be as far as i can understand; microSD is on mmc0 and the SDIO port is on mmc1
<apritzel>
MMC is the generic protocol name, used by SD cards, SDIO, and eMMC
<Jookia>
ah
<Jookia>
it looks like the driver never sets the voltage switch
<apritzel>
gnarface: yes, interestingly we never described the WiFi headers in the DT
<apritzel>
I guess because they are optional
<apritzel>
I mean the WiFi module is
<Jookia>
ok lets see
<Jookia>
the driver only supports setting a regulator to switch voltage
<apritzel>
and this is what the patch does: it adds the MMC1 port to the DT, enables it, and sets the regulators
<gnarface>
apritzel: that matches my experience here. as far as i can tell i'm the only one who ever even noticed the mainline kernel doesn't even activate the SDIO port
<apritzel>
Jookia: you don't need to *switch*, it can just run on 3.3V all the time
<Jookia>
no to get higher speeds you need 1.8v don't you?
<apritzel>
AFAIK that's fine for SDIO and eMMC, but not for SD cards
<Jookia>
oh
<apritzel>
sorry, I meant 1.8V
<Jookia>
oh
<Jookia>
the register is a little weirdly written
<gnarface>
two people in two other channels told me i'm going to have to use 1.8v and it seemed clear to them i was not, but that's already above my understanding of this code
<apritzel>
gnarface: vmmc-supply is to provide power to the device, vqmmc-supply is the voltage level for the I/O pins
<gnarface>
ok, that helps a little
<Jookia>
if you're up for trying a random patch i can hack something together for you to try
<apritzel>
if you follow that reg_eldo1, you will find it leads to the AXP PMIC (power management chip), and it sets that voltage rail to 1.8V
<gnarface>
hmmm
<Jookia>
hmm though
<gnarface>
so, are you saying i just have to set vmmc-supply to also use ®_eldo1 or what?
<apritzel>
gnarface: that patch is totally fine as such
<gnarface>
oh
<apritzel>
actually we should upstream it, just set the status to "disabled"
<apritzel>
(because the module is optional)
<gnarface>
i got the original version of this patch from a mailing list archive wherein moeicenowy was getting told "no" on a previous attempt to upstream it
<apritzel>
then people could just flip that to "okay", in U-Boot, via on overlay, or maybe even at runtime, in Linux (haven't tried that)
<apritzel>
gnarface: ah, yes, possible, because of the optional nature, I guess
<gnarface>
yea, they seemed to think it wasn't important enough hardware to mainline
<apritzel>
but the point is: the board is hardwired to those regulators and the other properties, so it describes the hardware
<apritzel>
I think we can send this patch with (keeping) status = "disabled", or put it in an overlay (.dtso)
<apritzel>
that would just contain that snippet, and can be applied on top of the .dtb, at boot time
<gnarface>
when i first started trying to make this work, someone mentioned something about it supposedly already being in an overlay in the kernel, but then i found out the hard way it wasn't at the same time i found out that i was the only one who ever tried it
<gnarface>
so i'm not sure how that communication broke down or when, but i am guessing a couple years back at least
<apritzel>
yes, that's how it works: if nobody cares enough to upstream it, nothing will happen
<gnarface>
despite that, i got it working without really understanding it, only recently to find out it's bottlenecking the wifi device because i haven't properly enabled "sd-uhs-sdr104"
<apritzel>
and I think the WiFi modules wasn't very popular
<apritzel>
I think I have one, though, so could test it
<apritzel>
gnarface: ah, that's good info, so the speed modes work, even for SDIO
<apritzel>
gnarface: are you talking about the official WiFi module from Pine64?
<gnarface>
apritzel: well, that's what people tell me anyway. i just wanna get more than 25Mbps out of the wifi, i thought it was my hostapd config at fault but extensive testing shows it's the kenrel
<gnarface>
apritzel: yes, it's the official wifi module still in the store
<gnarface>
apritzel: the board i have it on though, isn't the "Pine64 LTS V2" board they still sell though, it isn't even a V1, it's a earlier almost identical board now discontinued that they just called "Pine64 plus"
warpme has quit []
<apritzel>
I know, I have plenty of them ;-)
<gnarface>
ah, ok
<apritzel>
gnarface: so can you send plain-text emails? Do you want to upstream that patch? Happy to assist ...
<gnarface>
i think the only real difference is the newer boards have a emmc connector and a different ethernet device
<apritzel>
gnarface: yes, plus SPI flash
<apritzel>
and the DRAM is different (LPDDR3 vs DDR3)
<gnarface>
i can send plain text emails, but they're never gonna accept a patch from me
<apritzel>
why not?
<gnarface>
i've been libeled
<apritzel>
it would be Icenowy's patch anyway, since she wrote it, but you can send it on her behalf
<gnarface>
it would be best for someone with good street cred to take this and run with it
<gnarface>
and they already refused it from Icenowy, as i said... i was only able to find this patch attached to the mailing list archive of them refusing it
<gnarface>
and really... first i'd want the UHS working if it's actually supposed to work
<apritzel>
gnarface: do you have a link to that original post from MoeIcenowy ?
<gnarface>
gosh, no i didn't save the link... i can try to search it up again but it was already a year or two old when i found it...
<apritzel>
gnarface: but you said it does, right? And you get higher bandwidth out of it?
<apritzel>
no worries, I can search myself
<apritzel>
or wait a few hours for her to wake up ;-)
<gnarface>
apritzel: no, no that's the whole reason i came to you guys for help today noticing you were talking about A64 hardware; dmesg confirms i only get "high speed" linkup out of this, but various people have alleged it's supposed to be getting UHS (the next speed category up)
<gnarface>
one person suggested i maybe could just literally add "sd-uhs-sdr104;" to it and that would work, but i tried and it changed nothing
<gnarface>
and i don't care if it won't make the microSD slot any faster, it's fast enough as-is. the wifi is what's suffering
<apritzel>
can you post the relevant dmesg parts (or the whole thing?)
<gnarface>
yea it's just one line stand by
<apritzel>
what's the WiFi chip on it? RTL8723BS?
<gnarface>
yes, that looks right
* apritzel
reaches for that junk box ...
<gnarface>
hang on, this might help, i think the original patch file was called: v6-9-9-arm64-allwinner-a64-enable-Wi-Fi-for-Pine64.diff
<gnarface>
and as of me finding it, it was widely assumed to be redundant to work already mainlined, which i found to be false
<gnarface>
so maybe i actually own the only two of these in existence
<gnarface>
apritzel: here's the one line from dmesg: [ 0.723383] mmc1: new high speed SDIO card at address 0001
<apritzel>
thanks for the patch title, found it
<gnarface>
(there's one just like it for mmc0 but i don't really care if the microsd slot is limited to "high speed" since it's unlikely the flash itself can go much faster anyway, and disk access for typical use of this device as a wifi router is minimal)
<gnarface>
yes, confirmed it's rtl8723bs
<apritzel>
indeed, found that little board myself surprisingly quickly
<apritzel>
I am pretty hopeful we can upstream this, either as a .dtso, or with status
<apritzel>
... disabled
<gnarface>
any chance of getting UHS speeds out of it though?
<apritzel>
I will have a try
<gnarface>
i think it should be upstreamed, but i'm biased
<apritzel>
do you have those reports of it working from this very board?
<apritzel>
I mean the official Pine64 WiFi module
<apritzel>
(though I guess they was never anything else for those headers out there, officially)
<apritzel>
gnarface: so judging by the 8723 datasheet, on the radio side it supports up to 135 MBit/s only anyway, which would still be less than the 200 MBit/s in high speed mode?
<apritzel>
gnarface: please note that MMC high speed means 50 MHz, at 4 bits bus width that's 25 MByte/s, or 200 MBit/s (since you wrote 25 Mbps above)
<libv>
anyone ever heard of Giada Tech Ni-A20?
<libv>
it seems to be a allwinner a20 board with more features and ports than even a cubietruck
<apritzel>
btw: I think the 25 MB/s on the SD cards is a real bottleneck these days, even quite cheap SD card go way beyond that, in real terms
<apritzel>
libv: gosh, I was arguing that A64 is quite old lately, but A20 ...
<apritzel>
nice board anyway, and for the proper price, at least :-D
<libv>
i grabbed two right away to make up for the high postage (even though italy is just a few 400kms away)
<libv>
originally one could have had an ATX io plate for it too, so it might be mini-itx compatible
<libv>
the EU should reduce trans-european postage costs, amazon manages np, why can't dhl/hermes/gls/ups
<gnarface>
apritzel: uh, no i don't have any first-hand reports of it working at UHS speeds on this board, but i also don't have any first hand reports of anyone else even using this wifi module at all. and yes, i meant megabits, as in i'm getting almost reliably 2MB/s
<libv>
oh, it's nano-itx
<libv>
itx form factors and modesetting are the only reasons why VIA technologies should be remembered
<gnarface>
apritzel: ... which seems conspicuously close to the limit of "high speed" SD class speed ratings, whereas my iw station dump tests shows it should be getting more like 6, so the wifi side isn't the bottleneck
<apritzel>
libv: ah, it must be real good: "The new Android 4.2, more humane, more safety" (on that wayback machine link)
<gnarface>
apritzel: (sorry, had to afk for a second but i'm back now)
<apritzel>
gnarface: that's really odd, since high speed SDIO should be ~ 200 MBit/s ...
<gnarface>
apritzel: wait, are we sure this math is right? i thought high speed mode was 25 megabit, not megabyte?
<gnarface>
yea, i'm not getting anything close to that
<gnarface>
not even seeing 12.5MB/s
<gnarface>
i get maybe 2, with brief bursts to 2.5
<gnarface>
but under guidance from the same person who first pointed out the discrepancy in my dmesg output, i did some wifi tests and the iw tool showed wifi linkup speeds in the high 50's with bursts to even 70
<gnarface>
so the assumption was the bottleneck was the "high speed" part, but i was going on the apparent mistaken diagnosis of that being 25 megabits, not megabytes, which would have seemed much more telling, being basically conspicuously identical to the limit of my transfer rates
<apritzel>
do you have debugfs mounted? (mount -t debugfs none /sys/kernel/debug) Can you do: grep mmc /sys/kernel/debug/clk/clk_summary?
<gnarface>
no, i don't have it mounted. i have to rebuild the kernel to enable that don't i?
<apritzel>
not necessarily, most kernel have it enabled (though it might not be mounted automatically)
<apritzel>
"grep debugfs /proc/filesystems" would tell you
<gnarface>
oh, huh. i didn't know this would work without a rebuild... there was something i saw about manually setting the SDIO speed after boot in here.... i wonder if that would work....
<apritzel>
btw: are you sure mmc1 is the WiFi card? The kernel numbering can be different from the DT name
<apritzel>
ah, wait, it said SDIO, so should be correct
<gnarface>
apritzel: absolutely certain because the wifi device wouldn't even power on without the patch in question
<apritzel>
are the more messages with "mmc1" in dmesg?
<gnarface>
if there's something obviously stupid i've overlooked here please tell me
<gnarface>
can i just echo a higher clock speed into a file here to force it to UHS mode?
<apritzel>
looks alright, the big number is the clock frequency in Hz, so it's 50 MHz, and at 4bits (=200 MBit/s) that should be plenty for your 50ish Mbps
<gnarface>
truthfully if i could even get it to 30 Mbps that would be enough
<gnarface>
(it's functional as-is for basic use but in my brash arrogance i decided i deserved to try Steam Remote Play over wifi)
<gnarface>
(20 Mbps is only almost enough for that)
<gnarface>
despite being under constant attack and in a neighborhood where the spectrum seems to be nearly saturated by too many other wifi hotspots, it has been very stable, but is there any possibility that having crowded spectrum could be forcing the driver into lower speed somehow?
<libv>
apritzel: any android 2.3 or higher is good in my book (that's when bionic gained LD_PRELOAD)
<apritzel>
gnarface: the SDIO interface speed should be totally independent of the link speed on the radio side. And I found multiple sites that confirm that SDIO high speed is 25 MBytes/s
<gnarface>
apritzel: alright, noted, that just makes this bottleneck an even bigger mystery though. you don't think i might have to actually lower the SDIO clock speed to make the wifi faster, do you?
<apritzel>
gnarface: you are not supposed to mess with that anyway. If the board imposes a frequency limit (bad traces), you can (and we do) limit the max frequency in the DT
<apritzel>
but otherwise it's up to negotiate between the MMC host controller and the device
<gnarface>
apritzel: it is supposed to be able to go to UHS speeds though, right?
<apritzel>
IIRC most Allwinner SoCs limit the MMC bus frequency to 150 MHz, which is still good for some 300 MByte/s in UHS-400 mode
<gnarface>
i think that's why this red herring occurred, because it seemed conspicuous to someone more experienced than me that UHS didn't show up in the dmesg
<apritzel>
gnarface: I don't know, that WiFi chip is pretty old, so i could well imagine it doesn't support UHS
<gnarface>
ironically the driver is bleeding-edge...
<apritzel>
the datasheet I looked at didn't say anything
<gnarface>
hmmm
<gnarface>
apritzel: if i just ran "echo 150000000 > /sys/kernel/debug/mmc1/clock" would that actually change the speed?
<apritzel>
gnarface: which driver? the one in staging? or that patch I've seen that's working on top of the "more mainline" rtw88
<apritzel>
gnarface: all files in there are "-r--r--r--", so no luck with that ...
<gnarface>
apritzel: uh, yea it's the r8723bs that was in staging still in the debian kernel that's now become oldstable. should i be using a different one?
<gnarface>
apritzel: uh.... my /sys/kernel/debug/mmc1/clock file is marked -rw------- ....
<apritzel>
I have seen WIP patches somewhere that build on top of that rtw88 driver
<apritzel>
ah, then you might have different debug options enabled or so
<gnarface>
apritzel: somewhere else i saw a tip for solving this issue for different hardware that included echoing a clock speed into a file somewhere here in debug, but i can't find the link again and i think it was unrelated hardware anyway, but it was something else with a SDIO bus not reaching its full speed
<apritzel>
I am on 6.1.0-13-arm64, that's the Debian 12 kernel from a while ago, I think
<gnarface>
apritzel: ugh. well thank you for your time, this has been very educational despite still being basically a dead-end. can you do me a favor if you get a chance to spark yours up and tell me if you can get faster than 2MB/s out of it?
<gnarface>
so far i don't have any first-hand accounts of what it can actually do, just vague allegations of what it's supposed to actually do
<apritzel>
I need to bring this up first, and my quick-and-dirty debug initrd doesn't support Wifi, but I will give it a try later
<gnarface>
i may try echoing a value into that file but at the moment i'm too scared
<gnarface>
i don't want to light it on fire
<apritzel>
I think somewhere in /sys/bus/mmc/devices it should report whether the SDIO interface of the WiFi chip supports higher speed modes in the first place
<apritzel>
or the "mmc" tool might tell us
<apritzel>
I am pretty sure it's a bit in one of those long registers, but need to look up which
<apritzel>
gnarface: what property did you add, exactly? sd-uhs-sdr104
<gnarface>
yea, i tried adding that but it didn't change behavior so i rolled back
<apritzel>
gnarface: yeah, that looks as expected
chewitt has joined #linux-sunxi
<gnarface>
i think i saw in the kernel build there was an option for extra debugging features for this wifi driver or the sdio bus that weren't on
<apritzel>
gnarface: can you check if the dmesg output changes with that property? Maybe it tries, but the device denies, or such?
<gnarface>
apritzel: yea, that was in fact the only indicator i knew to check. there was no change, still said "high speed" not UHS or ultra high speed or any variation of such (and obviously the wifi was still bottlenecked at the exact same threshold, i did check that too)
f_ has quit [Read error: Connection reset by peer]
<gnarface>
but even the exact string "sd-uhs-sdr104" i don't know for sure was right, as that was actually copied from the dts for a Rockchip board
f_ has joined #linux-sunxi
<gnarface>
there's some other files in /sys/kernel/debug/mmc1, do any of them tell you anything? "caps" contains 0x0000190f, "caps2" contains 0x00000000, "mmc1:001/state" contains 0x00000001... none of this means anything to me though
<apritzel>
that property is the correct name, it's listed in Documentation/devicetree/bindings/mmc/mmc-controller.yaml
<gnarface>
apritzel: hmm, looking at this file is very informative... what do you think the odds are that sd-uhs-sdr50, sd-uhs-sdr25, or sd-uhs-sdr12 would work where sd-uhs-sdr104 didn't? if i had known there were other variations of UHS i would have tried some of them
<gnarface>
apritzel: hmm, i don't at the moment, but i'm reading the description anyway... do you think this patch would fork for the debian current stable kernel?
<gnarface>
s/fork/work/
hexdump0815 has quit [Read error: Connection reset by peer]
<gnarface>
it certainly sounds related to the issue i'm seeing
<apritzel>
well, it allows to set the host capabilities, without changing the DT
<apritzel>
but the commit message also points at how "caps" decodes
<gnarface>
ah
<apritzel>
your value (0x190f) means no UHS (as you don't have that property in atm)
<apritzel>
with UHS you should see bit 19 set, so 0x8190f
<apritzel>
but just that the host side, at least it would tell us if the driver accepted that property
<apritzel>
it doesn't tell us anything about the device side, though
<gnarface>
so do you think it's insane or futile to try building it with sd-uhs-sdr50 instead of sd-uhs-sdr104?
<gnarface>
or do you think i should try building a kernel with this patch first?
<gnarface>
or should i just wait until you've booted yours to see what happens there?
<gnarface>
(i realize it may turn out to be purely academic if the bottleneck isn't actually related to this and there's every possibility something entirely else is wrong with the wifi driver)
hexdump0815 has joined #linux-sunxi
<apritzel>
you don't need to build a kernel to change that, it's purely a DT change. You can do this on the fly in U-Boot
<apritzel>
do you boot with EFI, or via some extlinux.conf or boot.scr?
<gnarface>
uh... it's either extlinux.conf or boot.scr with this one, let me check...
<gnarface>
yea, extlinux.conf
<gnarface>
i was using boot.scr before but changed to extlinux.conf after they fixed some bug that was preventing it from being used before
<gnarface>
however... you bring up u-boot and now i have a question
<gnarface>
should i have patched u-boot for this?
<gnarface>
because i didn't, i only patched the kernel des
<gnarface>
*dts
<gnarface>
i didn't even consider i'd have to change u-boot to make this work
<gnarface>
is that what i did wrong? should i have actually patched the u-boot dts with this same change?
<gnarface>
do i need to patch both kernel and u-boot dts?
<gnarface>
i only had to patch the kernel dts to make the sdio wifi device show up in the first place, but i wouldn't have had any way to know if i was supposed to patch both
<apritzel>
it depends on what your extlinux.conf looks like. I guess you load the .dtb from the SD card in there?
<apritzel>
if you run via UEFI, it would take U-Boot's DTB, unless you explicitly tell it otherwise
<gnarface>
(paste.debian.net strips off the leading whitespace, but doesn't actually boot without a blank line as the first line)
<apritzel>
but this looks like you load it from where you load the kernel
<gnarface>
yea, that's correct
<apritzel>
and yeah, if you managed to enable WiFi in the first place, you are on the right track
<gnarface>
i byte checked the rebuilt version to make sure it was loading the new version with "sd-uhs-sdr104" in it, but that was my literal only indicator anything had changed
<gnarface>
but i didn't know i could just mount debugfs at that time....
<apritzel>
/sys/firmware/devicetree/base/ shows the DT content the kernel got
<apritzel>
so you can verify that you booted the right thing