genii has quit [Quit: Morning comes early.... GO LEAFS GO!]
ojn has quit [Ping timeout: 240 seconds]
ojn has joined #linux-exynos
abordado_ has joined #linux-exynos
Wizzup_ has joined #linux-exynos
abordado has quit [*.net *.split]
Wizzup has quit [*.net *.split]
mszyprow|home has joined #linux-exynos
<mszyprow|home>
wwilly_: ping
<mszyprow|home>
wwilly_: I've also seen the net crash on XU3 here, while working from home
<mszyprow|home>
wwilly_: but this is quite hard to reproduce
<mszyprow|home>
wwilly_: did you observe anything that might help to reproduce it? i've tried to increase my netwok trafic to trigger it, but without any success
wwilly has joined #linux-exynos
<wwilly>
willmore, if this last commit was only for xu4 era, why is it on the core files? shouldn't be specific to xu4 and be in its particular file?
<wwilly>
as I understand, this patch is to set opp of different part of the board, in a relation with the bootloader
<wwilly>
if by any chance, we don't have the same bootloader, it could cause the weirdness I have?
<krzk>
wwilly: so you found your cause :)
<wwilly>
yep, I'm trying to revert that just to test
<krzk>
yeah, revert is the command you asked
<krzk>
Putti: ... so did you try disabling PM_DEVFREQ? :)
<krzk>
Putti: the other methods you mentioned do not look relevant, maybe except case if GPU power domain was going off-on-off etc all the time, but I doubt (there should be sysfs entries showing that)
<wwilly>
krzk, do you know which bus opp table is in collaboration with the lan chip? (which is part of usb stuff)
<wwilly>
by reverting 1019fe2c728003f89ee11482cf8ec81dbd8f15ba, it seems to work correctly again
<krzk>
wwilly: Should be FSYS
<wwilly>
maybe is just one of them that cause my trouble? maybe in a relation with the u-boot I have? maybe is the pandemic situation with venus and uranus aliened...
<krzk>
wwilly: Let me take a look more
<wwilly>
krzk, by the way, do you have a dictionary of all this naming/acronyme so a noobs can learn?
<wwilly>
about fsys, there is a shift with fsys and fsys2 that is more than simply adjusting numbers
<krzk>
FSYS is for USB 2.0 and 3.0, also PDMA and touch screen. FSYS2 is for MMC and SROMc
<wwilly>
uhm ok, and what fsys means exactly? pdma? sromc?
<wwilly>
the other I know
<wwilly>
between bus_fsys2_opp_table and bus_fsys_opp_table, there is one more value in fsys2, and before that commit, bus_fsys was using bus_fsys_opp_table
<wwilly>
yeah it's like I'm describing a map at young school ....
<wwilly>
and my description is wrong... like at school ...
wwilly has quit [Quit: Leaving]
wwilly has joined #linux-exynos
<mszyprow|home>
wwilly: could you try if disabling DEVFREQ at all helps without the revert?
<mszyprow|home>
wwilly: btw, which version of the uboot (source tree?) do you use?
<wwilly>
I don't know
<mszyprow|home>
version command
<wwilly>
I never managed to change it, so it must be one the hardkernel just before I shift to my own stock debian
<mszyprow|home>
wwilly: I will add it to my todo-check list
<wwilly>
mszyprow|home, you think it could be imcompatible version with this new change?
<mszyprow|home>
wwilly: anyway, a test with DEVFREQ disabled will be really helpful
<wwilly>
yep doing it
<mszyprow|home>
wwilly: maybe it sets some strange clocks configuration, which interferes with my change in a such way that some blocks gets overclocked
<wwilly>
which uboot are you using?
<wwilly>
if any
<mszyprow|home>
mainline
<mszyprow|home>
v2019.xx
<mszyprow|home>
(I don't remember exactly)
<mszyprow|home>
but there have been almost no changes there, so any mainline has the same clocks configuration for the last few years
<wwilly>
ok
<mszyprow|home>
wwilly: but I don't remember what hardkernel did in their fork
<wwilly>
mszyprow|home, its PM_DEVFREQ or ARM_EXYNOS_BUS_DEVFREQ ?
<mszyprow|home>
both
<mszyprow|home>
this will also disable dmc devfreq
<wwilly>
uhm
<wwilly>
now that you talk about dmc
<wwilly>
I remember they change uboot to have dmc command, and I boot with dmc 933, and with you overclocked suggestion before, it could make sense
<wwilly>
I will try to remove dmc stuff on my uboot config, without the revert but still PM_DEVFREQ and ARM_EXYNOS_BUS_DEVFREQ on
<wwilly>
nope still the same by removing dmc stuff in uboot config, will try without devfreq now
<mszyprow|home>
wwilly: uboot's dmc configuration is relevant only when DEVFREQ in the kernel is disabled
<wwilly>
ok
<wwilly>
by the way, devfreq for 10c20000.memory-controller is not working well with simple_ondemand
<wwilly>
it's not raising any frequency at all, even with high memory presure workload
<wwilly>
but it's another discussion
<mszyprow|home>
wwilly: devfreq is generally broken :/
<mszyprow|home>
wwilly: but the one for 10c20000.memory-controller should work a bit better than the the others
<mszyprow|home>
wwilly: mainly because it uses interrupt driven feedback instead of broken polling
<wwilly>
ok, but it's not working with me... I'm using a benchmarck that are doing only memory access, forcing cache miss on each access; pointer chasing, targeting a new cache line within the same memory page (limit page walk and tlb miss), in a random pattern (kill the prefetcher)
<mszyprow|home>
wwilly: could you send me this benchmark? (binary+a few words how to run it)
<wwilly>
mszyprow|home, it seems to be working with DEVFREQ
<wwilly>
but this version it's a pain in the ass to compile and run it
<mszyprow|home>
wwilly: well, static binary is preferred ;)
<wwilly>
I rewrote it on my own, more manageable the memory mapping
LiquidAcid has joined #linux-exynos
<wwilly>
mszyprow|home, do you want to compile statically and give you just the binary?
<wwilly>
mszyprow|home, I think it's working now, with DEVFREQ
<wwilly>
it's running for 5mins now without fault on ssh
<wwilly>
so something wrong with the value provided in this patch?
<mszyprow|home>
wwilly: WITH or WIITHOUT devfreq?
<wwilly>
without devfreq
<mszyprow|home>
hmm
<wwilly>
ah yeah sorry, without devfreq it's working
<mszyprow|home>
then there must be some interference between your uboot and current devfreq configuration
<wwilly>
I will just check with devfreq but old value on fsys
<wwilly>
if it make sense
<mszyprow|home>
could you send me /sys/kernel/debug/clk/clk_summary of your xu3 with DEVFREQ DISABLED?
<wwilly>
without uboot's dmc config?
psydruid has quit [Quit: killed]
freekurt has quit [Quit: killed]
JuniorJPDJ has quit [Quit: killed]
<mszyprow|home>
wwilly: yes, without changes to dmc
<wwilly>
ok, will do
<wwilly>
also, for the benchmark, if you wait a week, I will publish my version somewhere, my paper was accepted (at LCTES, Performance Optimization on big.LITTLE Architectures: A Memory-latency Aware Approach)
<wwilly>
and will share benchmarks and patches
<mszyprow|home>
wwilly: okay, no problem, I already have enough on my todo list
<wwilly>
:)
<wwilly>
I have another question non related, it's possible to execute video games or opencl kernel on the gpu with panfrost? I remember that it was working with the mali migard driver...
paulk-leonov has quit [Ping timeout: 250 seconds]
<mszyprow|home>
wwilly: i didn't do anything with panfrost driver yet
<wwilly>
ok, saddly my paper was targetting only cpu workload, because of missing driver for the gpu, I tried to use hardkernel migard version, but wasn't working well...
<wwilly>
this is without devfreq, without uboot dmc config, and ssh is working
psydruid has joined #linux-exynos
paulk-leonov has joined #linux-exynos
<wwilly>
mszyprow|home, its seems to be working with devfreq, but with old values on fsys related: https://pastebin.com/yRCuswLC
<wwilly>
mszyprow|home, do you want me to test something?
<mszyprow|home>
wwilly: not today
<mszyprow|home>
wwilly: i just collect information and I will take a look into this later
<wwilly>
a ok
<wwilly>
ping me when you put your nose on it, will continue working on my side on something else (merging the work of my paper in this last v5.6 version :) )
paulk-leonov has quit [Ping timeout: 240 seconds]
paulk-leonov has joined #linux-exynos
<wwilly>
mszyprow|home, by the way, do you have a good manual really easy step by step copy paste howto to use the mainline uboot for this xu3 board?
<wwilly>
to rely on more trustable software that hardkernel one
<wwilly>
not to blame them...
<mszyprow|home>
wwilly: I usually start from the Tizen precompiled images and replace uboot binary with the mainline one, leaving all the boot scripts
<mszyprow|home>
wwilly: but this is not the standard configuration I would recommend
<mszyprow|home>
wwilly: it uses custom scripts in uboot env
<mszyprow|home>
wwilly: you may also use some precompiled arch linux images, they have everything prepared for xu3/4
freekurt has joined #linux-exynos
JuniorJPDJ has joined #linux-exynos
LiquidAcid has quit [Ping timeout: 272 seconds]
wwilly__ has joined #linux-exynos
wwilly_ has quit [Ping timeout: 256 seconds]
wwilly_ has joined #linux-exynos
wwilly has quit [Ping timeout: 240 seconds]
LiquidAcid has joined #linux-exynos
<willmore>
wwilly_, I'm saying I only have XU4 era hardware to test on.
<wwilly__>
willmore, ok
genii has joined #linux-exynos
Turl has quit [Quit: >.<]
Turl has joined #linux-exynos
<willmore>
Sorry if that was confusing. I was beating my head against a bunch of boards yesterday and was probably not as coherent as I would like to be.
<Putti>
krzk, yes PM_DEVFREQ is disabled. I tried to look at the clock initialization code but I cannot find anything where it sets the clock speed. I wonder if linux doesn't do it at all when PM_DEVFREQ is not used, and instead only the clock speed set by bootloader / CPU RST are used.
<Putti>
I'm using sboot bootloader (the one that ships by default on i9305 phone)
<Putti>
krzk, if this is true, maybe the (leftbus) clock speed set by bootloader is not enough
<Putti>
I'm using the FIMD with HW planes and G3D so since both of them use LEFTBUS maybe the clock speed is not enough
<Putti>
before I used just the FIMD with HW planes and there was no glitches
<Putti>
(did the graphics rendering in software)
<wwilly__>
willmore, no worries :)
<Putti>
Could this be an issue with DMC bus also?
<Putti>
I have now enabled PM_DEVFREQ and maxing out the clock speeds for various buses in dts
<Putti>
with all the buses at max speed still glitching
<wwilly__>
mszyprow|home, did you screw everything up? :) just kidding
Wizzup_ has quit [Quit: Reconnecting]
Wizzup has joined #linux-exynos
<Putti>
Now I see the graphics glitch is a bit different looking than what it was earlier (the issue I linked from freedesktop gitlab instance), here is a video of it: http://git.putti.eu/video.AVI
wwilly__ has quit [Quit: This computer has gone to sleep]
wwilly__ has joined #linux-exynos
wwilly__ has quit [Client Quit]
mszyprow|home has quit [Ping timeout: 256 seconds]
Thistle has joined #linux-exynos
mszyprow|home has joined #linux-exynos
Thistle has quit [Quit: Leaving]
mszyprow|home has quit [Ping timeout: 260 seconds]
mszyprow|home has joined #linux-exynos
mszyprow|home has quit [Ping timeout: 265 seconds]
LiquidAcid has quit [Quit: Leaving]
<Viciouss>
I'm having some trouble getting the power button to wake up my galaxy note 10.1 from sleep, I'm using the android mainline 5.5 kernel currently with gpx2-7 configured as gpio-keys and marked as wakeup-source, evtest is reporting the key event just fine but the device will not come back from sleep when pressing the button
<Viciouss>
in the kernel log I can see that wake gets enabled and samsung-pinctrl is setting the interrupt mask for external wakeup
<Viciouss>
I also tried pm_test and the device is going to sleep and gets back up just fine, so it shouldn't be one of the drivers crashing on sleep
<Viciouss>
this is a exynos 4412 btw, any help appreciated
<Viciouss>
just found that gpx1-3 works fine as wakeup source
<Putti>
Viciouss, I don't know solution to your problem but can I ask if you know why I'm usb devices are not detected on 4412 even if MUIC sets USB path? I'm thinking maybe I'm setting some USB drivers wrong. I have DWC2 in Dual-role mode.
<Putti>
USB path meaning CONTROL1 = 0x09, CONTROL2 = 0x04
<Viciouss>
I'm also unable to get anything on the USB port working currently but haven't had a closer look at it yet, for the note 10.1 the original 3.0 drivers and gpios related to USB are difficult to follow
<Putti>
Viciouss, I'm able to use the USB port in gadget mode
<Putti>
meaning I get serial console over usb
<Viciouss>
I had to solder a serial cable which works just fine but it's annoying because I have to switch cables to transfer data to the device in recovery, I really need to fix this
<Putti>
ah, yes, I've been thinking also making some sort of computer controller relay board that could switch the cables for me without having to physically remove any cables.