<apritzel1>
also Rockchip would benefit from it as well
domidumont has quit [Read error: Connection reset by peer]
vishnup has joined #linux-sunxi
<apritzel1>
plaes: regarding the Kconfig.platforms: You _can_ select a single platform with this, but defconfig enables them all so far to get a better (compile) test coverage
<apritzel1>
plaes: also this is to encourage distributions to automatically have support for all supported hardware
domidumont has joined #linux-sunxi
premoboss has quit [Ping timeout: 240 seconds]
premoboss has joined #linux-sunxi
<oliv3r>
libv: i see no talk from you this year in the graphics devroom
<oliv3r>
i am dissapointed :(
<oliv3r>
who of you guys btw will be joining the sunxi dinner?
<oliv3r>
@FOSDEM2016 that is
bmeneg has quit [Quit: \o]
GeneralS1upid is now known as GeneralStupid
reinforce has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
arossdotme-planb has quit [Ping timeout: 272 seconds]
Worf has quit [Quit: Konversation terminated!]
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
hipboi has quit [Quit: This computer has gone to sleep]
cptG_ has quit [Remote host closed the connection]
cptG has joined #linux-sunxi
<ssvb>
KotCzarny: how is your Orange Pi PC USB hard drive doing now? did the problems disappear?
<KotCzarny>
ssvb, didnt test it yet, right now im recompiling kernel with diff. options
<KotCzarny>
slub oopses hard ;)
<KotCzarny>
slab works
<ssvb>
why are you recompiling the kernel? just simply reduce the DRAM clock speed and try your USB hard drive tests again
<KotCzarny>
ssvb, its unrelated to memspeed
<KotCzarny>
i wanted to change loboris kernel options into something more suited for me
<ssvb>
it's better to try *one* thing at a time
<KotCzarny>
yes
<KotCzarny>
doing it that way
<KotCzarny>
that's why i found that its the slub breaking my config
<ssvb>
if the USB reliability problems have disappeared after reducing the DRAM clock speed while keeping the same kernel, then this was it
<KotCzarny>
ssvb, will notify you with the the test results, but that's after i get my kernel
<ssvb>
if you are also changing the kernel, then this is already not a clean test
<KotCzarny>
i still have loboris kernel as a safe one
<KotCzarny>
so its not a problem
<KotCzarny>
will test on both
<wens>
vishnup: hey, any updates on a83t stuff?
<ssvb>
ok, thanks
<wens>
vishnup: fyi i'm also looking into it
<montjoie>
hello I have done https://bpaste.net/show/b4bb6173d51f for adding i2c on a83t, but I am puzzled the usermanual give two set of 2 pin for twi2_xxx. normal ?
<wens>
yeah, it's normal
<wens>
fyi you should only mux the pins you are actually using
<wens>
2 sets just mean you get 2 choices when designing the board
<montjoie>
I see that it exist also a R_TWI, does is this the same as a31 p2wi ?
Net147 has quit [Ping timeout: 264 seconds]
<montjoie>
the a83t just give the memory address and nothing more
<ssvb>
apritzel1: "the root compatible string was exactly the culprit of my UART issue" - do I understand it right that you made some nice progress with pine64/a64 clocks support and dts/dtsi?
<montjoie>
there are lots of R_device (and a pinctrl-r), whats does means R ?
Net147 has joined #linux-sunxi
<plaes>
someone is complaining that wiki emails aren't coming through...
<plaes>
libv ^^
<plaes>
Turl ^^
bmeneg has joined #linux-sunxi
naobsd has joined #linux-sunxi
<wens>
montjoie: r_twi is an i2c controller in the r_ block
<wens>
in the r_ block means it is supposed to be used by the arisc controller
<montjoie>
So I could ignore it ?
<wens>
yes
<montjoie>
and all others R_device, and pinctrl-r also
<wens>
yes
<ssvb>
wens: does it mean that arm has no access to these R_* devices? Or is it just a hint about the intended use?
<wens>
a hint
<ssvb>
ok, that's good to know
<apritzel1>
I guess those _can_ be configured to be secure only, if I got this right
<ssvb>
RSB also has the R_* prefix on A64, and I'm going to take care of the AXP803 PMIC on this weekend for U-Boot
vishnup has quit [Quit: Connection closed for inactivity]
<ssvb>
if it is accessible from the ARM cores, then this makes everything quite easy
<ssvb>
but of course, we can also make a simple arisc firmware for controlling it too
<apritzel1>
ssvb: going for Linux accessing the RSB directly is a good start, I think
<apritzel1>
much quicker success, I guess ;-)
<apritzel1>
also we can amend this later via DT, by not providing a RSB node, but a new firmware interface node instead
<ssvb>
apritzel1: btw, I don't mean to hurry you up, but if you have some useful a64 kernel patches ready, then pushing them to github would be very much appreciated
<apritzel1>
ssvb: I know, would appreciate that, too
<apritzel1>
;-)
<ssvb>
ok, thanks :-)
<apritzel1>
I guess I push something tonight
<apritzel1>
these will need discussion on the list anyway ...
<apritzel1>
ssvb: the background of the delay is that a) I want something that actually works ;-)
<mripard>
apritzel1: I'd also say that you don't really need the clocks at first, something that boots up to an initramfs is fine for a first set
<apritzel1>
and b) I want to do it in a way that is more future-proof, enabling future SoCs to be potentially supported _without_ kernel patches, just by DTs
<apritzel1>
mripard: I see
<apritzel1>
mripard: I will order the patches accordingly, then
apritzel1 is now known as apritzel
<apritzel>
mripard: btw: it is the regulator the causes the MMC driver's probe to be deferred
<apritzel>
which is weird because it is a simple "fixed-regulator"
<apritzel>
mripard: thought so too, but it's on :-(
<apritzel>
is there some debugfs/sysfs interface to list known regulators?
<apritzel>
similar to /sys/kernel/debug/clk?
<ssvb>
the drivers initialization order is probably not well defined and prone to fail
<mripard>
apritzel: yeah
<mripard>
regulator/regulator_summary ;)
<apritzel>
but this PROBE_DEFER mechanism should take care of that, shouldn't it?
<apritzel>
mripard: that was too obvious ;-)
<ssvb>
well, this probe defer stuff fails for USB OTG, so something must be rotten in it
<ssvb>
afaik nobody cared to fix it properly yet :-)
<mripard>
ssvb: when attaching a gadget to it ?
<ssvb>
mripard: when statically compiling USB OTG related driver (for NFS), I don't remember the exact details
<mripard>
yeah
<mripard>
it was a bug in the USB stack
yann|work has quit [Remote host closed the connection]
<mripard>
if the gadget device was registered before the OTG controller, things were not working
<mripard>
it's fixed in 4.5
<ssvb>
oh, that's nice
<mripard>
I'm guessing your patch just made the OTG controller probe earlier than the gadget driver, making the whole thing work
<wens>
mripard: oh it is?
<mripard>
yeah
<mripard>
commit 855ed04a3758
<oliv3r>
mripard: I'm sad you are not fosdemming this year :(
<mripard>
the patches were floating around for quite some time, it took way more time than it was supposed to over a pointless debate
<mripard>
but it's merged now
<wens>
very nice!
<apritzel>
mripard: I take it your for-next branch is the right one to base on?
<apritzel>
mripard: and also that's a moving target?
<oliv3r>
oh that's really nice!
<oliv3r>
while the work around was easy, it was still annoying
<wens>
apritzel: mripard's for-next only has sunxi patches for arm-soc, if you want stuff including sunxi patches from other subsystems you can use sunxi-next
<mripard>
apritzel: it's the branch that is pulled into linux-next, and the collection of patches I'll send to the arm-soc and clk maintainers
<apritzel>
wens: mripard: thanks for heads up about the different subsystems
<apritzel>
I guess I don't need arm-soc, that should simplify this a bit
<apritzel>
but clocks will become interesting ...
tomboy65 has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 245 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 248 seconds]
cnxsoft has quit [Quit: cnxsoft]
nashpa has joined #linux-sunxi
huawei has quit [Ping timeout: 256 seconds]
huawei has joined #linux-sunxi
Ueno_Otoko_ has quit [Ping timeout: 264 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 240 seconds]
<KotCzarny>
most likely the last one was damaged in the same way
<tkaiser>
Thermal throttling, all CPU cores shutdown except of cpu0, constantly DRAM clockspeed adjustments, even Mali clocked down
<tkaiser>
Did any of you with Pine64+ experienced the same?
<WarheadsSE>
tkaiser: I don't think any of us have the + yet
<apritzel>
tkaiser: are you sure that the CPUs are actually disabled?
<tkaiser>
No idea, this is f*cking Android. Never did anything with it ;)
<apritzel>
looks like they are suspended and then brought up again
<tkaiser>
According to serial console the kernel tries to bring back cpu1 from time to time and then kills it immediately again
<apritzel>
and for your peace of mind, my Android log looked very similar
<tkaiser>
Ok
<apritzel>
lots of scary messages all over the place
<apritzel>
to me it looks like a over-reacting load balancer or the like
<WarheadsSE>
Fairly expected these will need a heat sink on them
<apritzel>
like: oh, there is work to do, lets bring up another core, oh wait, it's finished, let it sleep again
<apritzel>
tkaiser: there are for instance 1.5 seconds between bringup and shutdown
<apritzel>
and I also saw mmc errors
<apritzel>
tkaiser: you should switch to a sane image ;-)
<tkaiser>
apritzel: Yes, I will stop this Android crap now. It boots and spills out weird messages == no DOA
<apritzel>
tkaiser: \O/
<apritzel>
see: you learn to love the small things ;-)
<apritzel>
WarheadsSE: the Pine64+ is the one with either 1GB or 2GB RAM, AFAIK most developers got a Pine64+ with 1GB so far
<tkaiser>
Unfortunately no time at all to play with it now. Busy doing normal work: image metadata injection, a PDF/A+ZUGFeRD workflow has to be finished and a weird OS X + Solaris storage/backup/archive concept finished.
<tkaiser>
See you next week ;)
<apritzel>
sounds like fun ...
<wens>
allwinner sdk just does cpu hotplugging all the time, no need to worry
<KotCzarny>
wens, does it save any noticable power that way?
<wens>
KotCzarny: never did any testing on that front
<KotCzarny>
hmm
<KotCzarny>
using xz for kernel compression, 3.2MB -> 2.2MB
<KotCzarny>
which is noticeable because uboot reads kernel from sd at ~900kB/s
<apritzel>
tkaiser: so you have the WiFi module already, nice
<wens>
afaik the pre-prod board they sent out is the pine64+ w/ 1GB ram
<apritzel>
wens: yes, that is what I think too
<ssvb>
apritzel: I also got the wifi module and the IR receiver in my Pine64+ package
<apritzel>
AFAIK the 2GB version has just arrived this week
<wens>
mine is scheduled for march
<apritzel>
wens: really? Via the normal backer scheme?
<wens>
which is fine given i'll be away from my boards for a month
<wens>
apritzel: yeah
<apritzel>
if you are interested, I can ask TL about a board for you
<wens>
i already have a pre-prod one, just haven't gotten around to playing with it :)
<apritzel>
wens: Oh, I see
<ssvb>
KotCzarny: but the xz decompression takes more time, and only 900kB/s for the SD card read seems way too slow
naobsd has quit [Remote host closed the connection]
<KotCzarny>
ssvb, decompression is fast, as for read speed, what can be the cause?
<wens>
slow card?
<wens>
what class sd card do you have?
<KotCzarny>
wens, when booted read speed is ~18M/s
<buZz>
class -5
<buZz>
:P
<ssvb>
KotCzarny: I get ~10 MB/s kernel image read speed from SD in U-Boot on my Pine64, maybe I need to check the Orange Pi PC too
<KotCzarny>
ssvb, i suspect spi mode being used in uboot
<ssvb>
KotCzarny: how did you measure the decompression speed?
<KotCzarny>
ssvb, i didnt, but there is no noticable lag between kernel finishing loading and booting messages flowing from kernel
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 264 seconds]
<KotCzarny>
measuring can be probably done by piping serial output into some tool that timestamps the line as they come in
vishnup has quit [Quit: Connection closed for inactivity]
tomboy65 has quit [Read error: Connection reset by peer]
<GeneralStupid>
hi, is it possible to use flashbench without reformatting?
<KotCzarny>
yes
<KotCzarny>
did you read the readme?
<GeneralStupid>
:D
<GeneralStupid>
What do you think?
<ssvb>
KotCzarny: there is one trick about the DRAM clock speed, the 3.4 kernel updates the DRAM clock frequency when it crosses the cooling trip points
tomboy65 has joined #linux-sunxi
<GeneralStupid>
KotCzarny: yes i read that. But it have to be unmounted? And what do i do with the results?
<ssvb>
KotCzarny: in your case the mainline U-Boot initializes the DRAM clock speed as 624MHz, but if the SoC temperature raises to 70C even once, then the DRAM frequency scaling code sets it to 672MHz
<ssvb>
KotCzarny: or whatever is the DRAM clock speed value in the FEX file
<KotCzarny>
GeneralStupid: flashbench has read only mode which means you dont have to umount
<KotCzarny>
ssvb: but i saw only one occurance in that fex file
<GeneralStupid>
KotCzarny: the readme from github is really short... can i optimize the blocksize in my FS without reformatting?
<KotCzarny>
GeneralStupid: unless ext4 has some online support for stride/strip yes, but unlikely
<KotCzarny>
dont know about other fs
<GeneralStupid>
KotCzarny: iam an ext4 guy
<KotCzarny>
ssvb, offtopic, installed fbturbo on opipc, it works, but when i turn off compositor in wm, then gtk windows lose content when scrolled, is it known?
<ssvb>
"Eric Anholt looks to *further boost* its performance" and "I'll be sending a separate patch to accelerate a8 rendering on GLES2-class renderers, but *even with that things are crazy slow*"