s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
kaspter has joined #linux-rockchip
vstehle has quit [Ping timeout: 240 seconds]
steev has quit [Read error: Connection reset by peer]
steev has joined #linux-rockchip
<macc24>
does anyone know why the heck rk817_battery and rk817_charger are so big?
<WoC>
Maybe they are made in San Antonio, Texas ;)
<macc24>
WoC: i think we both agree that this wasn't funny
<WoC>
my bad, even for after hours joke
vstehle has joined #linux-rockchip
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
<inode>
lol
warpme_ has joined #linux-rockchip
<macc24>
mps: that poor mali t860mp4 is driving a 2400x1600 screen on kevin
<macc24>
don't be too harsh for it
<macc24>
gpu performance is literally the only reason why i'm still using chrome on my kevin
psydruid has quit [*.net *.split]
afaerber has quit [*.net *.split]
afaerber has joined #linux-rockchip
MartijnBraam has quit [Ping timeout: 244 seconds]
Ke has quit [Ping timeout: 244 seconds]
nergzd723 has quit [Ping timeout: 265 seconds]
paulk-leonov has quit [Ping timeout: 240 seconds]
paulk-leonov has joined #linux-rockchip
ldevulder has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
nergzd723 has joined #linux-rockchip
stikonas has joined #linux-rockchip
paulk-leonov has quit [Ping timeout: 268 seconds]
paulk-leonov has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
psydruid has joined #linux-rockchip
Ke has joined #linux-rockchip
field^Mop has joined #linux-rockchip
Net147 has quit [Quit: Quit]
Net147 has joined #linux-rockchip
<mps>
macc24: it is not bad at all, I'm using linux on kevin from day I bought it
<mps>
macc24: and I use only rockchip drm driver, just play sometimes with panfrost
<mps>
though yes, I don't need gpu intensive application, only mpv but also it is quite fine without gpu
<mps>
macc24: it is strange but what keeps me to fully switch X to use panfrost is st term, because it is very slow in 'input' characters from keyboard when run with panfrost
<DuClare>
Anyone got performance numbers for rk3288 gmac? I can't even reach 200 Mb/s transmit, and that sounds suspiciously low
<macc24>
mps: try wayland
<macc24>
it runs much better imo on rk3399
<macc24>
DuClare: what did you use to test this?
<DuClare>
iperf3 on custom board running 5.4.95
<mps>
macc24: I tried, but awesome wm don't run on wayland, so wayland is not for me
narmstrong has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
steev has joined #linux-rockchip
steev has quit [Remote host closed the connection]
steev has joined #linux-rockchip
narmstrong has joined #linux-rockchip
BenG83 has joined #linux-rockchip
<DuClare>
Hmm is there any way to generate 125MHz from 25MHz ext_gmac clock?
<robmur01>
I don't think you can get 5GbE that easily :P
<macc24>
DuClare: isn't it maxing out gigabit ethernet?
<DuClare>
No, I just said I'm not even reaching 200 Mb/s
<macc24>
gigabit ethernet maxes out at 125MB/s
<macc24>
waaaaait
<macc24>
mps: when you are rendering anything opengl/gles you are using panfrost, or should be using panfrost
<robmur01>
more seriously though, in RGMII mode doesn't ext_gmac represent the clock provided by the phy?
<robmur01>
if that's not already 125MHz then something seems wrong :/
<mps>
macc24: right. but if I don't modload panfrost driver then gpu is not used and all 'job' is done by cpu
<mps>
macc24: i.e. swrast driver. 'GLX: Initialized DRISWRAST GL provider for screen 0'
<macc24>
mps: if swrast is faster than panfrost on glamor this says something about glamor, not panfrost
<mps>
macc24: for most 2D 'rendering' it is quite fine (bearable)
alpernebbi has joined #linux-rockchip
<mps>
macc24: I'm not 'graphic man' so my knowledge about these things is low
<mps>
and ime, all these 'things' about different arm SOCs/SBCs is like some black/white magic
<macc24>
._.
<mps>
for example on my gru-kevin (rk3399) plugging usb multi dongle on left usb-c can't recognize r8152 ethernet but on right side connector it works fine
<mps>
macc24: we talked on other channel about mediatek elm chromebook (you remember), and no matter what I try to connect usb-c external disk doesn't work
<macc24>
have you tried other disk or usb port?
<mps>
tried with few transcend and kingston ssd disks with their cables, tried with two separately bought high quality cables, no luck
<macc24>
dmesg?
<mps>
as I'm curious and have 'strange' ideas, I took usb-c cable from power supply of my son apple M1 macbook and it works like a charm
<mps>
now solutions looks like to buy apple M1, throw it in trash and just keep cable :)
<macc24>
yeah you can do that, just tell me where you trash can is
<mps>
:D
<mps>
macc24: you have gru-kevin?
<macc24>
yep
<mps>
I made kernel for it for alpine linux
<macc24>
i heard about this
<macc24>
on #linux-mediatek probably
<mps>
no, on #linux-mediatek I told about linux-elm, kernel for elm chromebook
<mps>
ah yes, now I remember, that is your work to get better and easier installation on some chromebooks
<macc24>
some chromebooks -> whatever i have on hand that isn't well supported by other linuxes
<macc24>
it'd be nice to get it running on qcom chromebook
<mps>
ime, Arch linux alarm have best support for chromebooks
<macc24>
does duet run on alarm?
<mps>
I don't know really
<mps>
but five years ago it was really easy to install alarm on my first chromebook, samsung exynos-5800 (Peach Pi)
<macc24>
if i used alarm, alarm rootfs would be supported in cadmium lol
<mps>
but after some time I found that alpine is a lot faster on arm cpus, and I switched everything to alpine
<macc24>
oh it is?
<mps>
my mail,web,matrix server, home router run on old lamobo r1 with mmc for all filesystems for about 4 years, quite fine
<macc24>
i run my *inhales* nas, bouncer, dns, ssh proxy, web server and weechat box runs on dualcore intel atom that is almost my age
<mps>
oh yes, I forgot irssi, wireguard, fwknopd, firewal and openvpn also on this old lamobo
<macc24>
mps: can you take a shot at adding alpine linux to cadmium?
<macc24>
i'm curious how hackable it is for uninvolved person
<mps>
macc24: I will look but can't promise anything, my free time nowadays is used to make alpine armv7 to install and run easy under qemu
nroberts has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 268 seconds]
vstehle has quit [Quit: WeeChat 3.0]
<DuClare>
Woohoo 330Mb/s
vstehle has joined #linux-rockchip
vstehle has quit [Ping timeout: 246 seconds]
matthias_bgg has joined #linux-rockchip
kaspter has quit [Quit: kaspter]
s_frit has quit [Ping timeout: 265 seconds]
<DuClare>
Hopeless :(
kaspter has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
<DuClare>
Ok I can get a clock from npll
<DuClare>
Any idea if there's a way to generate 125MHz with it though?
<DuClare>
By default I get npll = 500 MHz and mac_pll_src = 41.666667 MHz
<DuClare>
I guess it picks something by automagic but where's the logic for that?
<DuClare>
500 MHz / 4 would give me 125 MHz..
<DuClare>
rk3288.dtsi cru assigns 500MHz to npll, ok.. but then where is the decision made to divide it by 12?
<DuClare>
mmind00 smack me with a cluebat? ^
<mmind00>
DuClare: no violence :-D
<DuClare>
Hmm.. ok, would you touch me gently with a cluebat. ^^
<mmind00>
DuClare: I'll try I guess you want SCLK_MAC (mac_clk) at 125MHz, right?
<DuClare>
Yes, that's the goal
<mmind00>
DuClare: SCLK_MAC has already a CLK_SET_RATE_PARENT, so in theory the mux should try to select mac_pll_src (seeing that ext_gmac won't provide a matching source) and try to set a suitable clock for that
<mmind00>
DuClare: I'm not sure about the dwmac if it contains a clk_set_rate ... but you could just try "assigned-clocks = <&cru SCLK_MAC>; assigned-clock-rates = <125000000>;" in your board dts in the &gmac node?
<DuClare>
I'll try that
<mmind00>
other thing would be if the driver itself does try to set the clock to something else
<DuClare>
Oh yeah. I don't think it does unless I missed it
<DuClare>
I was missing the fact that you can set assigned clock rates on gmac
<DuClare>
Thanks a lot mmind00 :)
<mmind00>
DuClare: Yay ... and see no violence necessary
Net147_ has joined #linux-rockchip
Depau has joined #linux-rockchip
Net147 has quit [*.net *.split]
paulk-leonov has quit [*.net *.split]
robmur01 has quit [*.net *.split]
Depau_ has quit [*.net *.split]
urjaman has quit [*.net *.split]
<DuClare>
Now I just need to calibrate rx & tx delays and hope to find something that actually works :)
robmur01_ is now known as robmur01
robmur01 is now known as 17SABVDEO
Depau_ has joined #linux-rockchip
urjaman has joined #linux-rockchip
robmur01 has joined #linux-rockchip
robmur01 has quit [Ping timeout: 254 seconds]
Depau_ has quit [Ping timeout: 254 seconds]
17SABVDEO is now known as robmur01
<macc24>
mmind00: wtf just happened
<macc24>
i made a random change in rk808.c
<macc24>
and battery started working
<macc24>
i don't know why
<macc24>
i don't want to know why
<macc24>
that's seriously cursed
vagrantc has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
<mmind00>
macc24: I guess that depends on what your random change was :-D
<macc24>
._________.
<mmind00>
macc24: also maybe that just caused a recompile of that part
<macc24>
mmind00: i'm going to assume that it was dragons messing with my code when i'm asleep
<mmind00>
macc24: :-D
archetech has joined #linux-rockchip
putti__ is now known as Putti
<DuClare>
Hmh, looking about as bad as with external 125MHz clock.. :|
<DuClare>
Am I supposed to reset PHY after adjusting tx delay?
<DuClare>
I never did when running at 25 and 42 MHz and it seemed to work just fine
<DuClare>
rockchip-dwmac.txt> clock_in_out: For RGMII, it must be "input", means main clock(125MHz) is not sourced from SoC's PLL, but input from PHY; For RMII, "input" means PHY provides the reference clock(50MHz), "output" means GMAC provides the reference clock
<DuClare>
I'm getting confused here
<DuClare>
Here it sounds like you can't use PLL
hexdump0815 has joined #linux-rockchip
<DuClare>
On the other hand, RK3288 TRM v1.2 Part 1 says on page 625 that in RGMII mode, clock architecture only supports that TX clock source is from CRU "as following figure" (insert figure with [PLL] -> [DivFree] in CRU -> clk_tx in GMAC)
<DuClare>
That almost implies you can *only* use PLL
<DuClare>
Sigh
kaspter has quit [Quit: kaspter]
<robmur01>
but see figure 2.4 - the CRU can still derive that clock from gmac_clkin rather than the PLL sources
<DuClare>
Yes
<DuClare>
That's why I figured I can use either gmac_clkin or PLL
<DuClare>
Why does rockchip-dwmac.txt sound like it's saying PLL cannot be used in RGMII mode?
<DuClare>
Looks like the driver enables clk_mac_refout if clock_in_out is output. But only in RMII mode. Also it sets clk_mac rate, but again only in RMII mode
<DuClare>
So clock_in_out is a no-op in RGMII mode, unless I missed something
<robmur01>
I'd imagine because the nuance that that's how it's *expected* to be used got lost in translation - I assume the key point is that RGMII definitely doesn't need it to be an output, and whoever wrote the binding figured things would always be wired up to provide the correct clock from the phy.
dvergatal has quit [Ping timeout: 260 seconds]
<DuClare>
Yeah, I guess. I'm kinda back to square one :)
wens has quit [*.net *.split]
azend has quit [*.net *.split]
arnd has quit [*.net *.split]
dlezcano has quit [*.net *.split]
maz has quit [*.net *.split]
samueldr has quit [*.net *.split]
alpernebbi has quit [Quit: alpernebbi]
azend has joined #linux-rockchip
dlezcano has joined #linux-rockchip
wens has joined #linux-rockchip
arnd has joined #linux-rockchip
samueldr has joined #linux-rockchip
maz has joined #linux-rockchip
samueldr has quit [Max SendQ exceeded]
samueldr has joined #linux-rockchip
robmur01_ has joined #linux-rockchip
robmur01 has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-rockchip
hexdump0815 has quit [Ping timeout: 240 seconds]
archetech has quit [Quit: Konversation terminated!]
warpme_ has quit [Quit: Connection closed for inactivity]