Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
cptG_ has quit [Ping timeout: 244 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
paulk-collins has quit [Quit: Leaving]
Da_Coynul has joined #linux-sunxi
station has joined #linux-sunxi
bugzc has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ssvb has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
scream has quit [Remote host closed the connection]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Colani1200 has joined #linux-sunxi
<wens> MoeIcenowy: yes this seems to be the issue i mentioned, that the check of the dotclock for the display mode is too strict
<wens> MoeIcenowy: try enabling more DRM logs
<mdsrv> one quick question
<mdsrv> before i go to sleep
<wens> by setting drm.debug=0x1e # see http://lxr.free-electrons.com/source/include/drm/drmP.h#L96 for what the values mean
<mdsrv> have u ever got an issue with libgl?
<mdsrv> SEGFAULT etc
<mdsrv> gles_glBlendFuncSeparate is NULL
<mdsrv> and then segfault
<mdsrv> armbian/h3/bananapi m2+
<wens> i personally have not run GL on my devices, as ARM has not provided distributable blobs
Colani1210 has quit [Ping timeout: 260 seconds]
<mdsrv> ok
<wens> and i only run mainline, not the 3.4 kernel
<mdsrv> why mainline
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<wens> mdsrv: because i mostly develop, and seldom use it for daily purposes?
<mdsrv> ok
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
fdcx_ has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
fdcx has joined #linux-sunxi
fdcx_ has joined #linux-sunxi
<MoeIcenowy> wens: but no CRTC is found...
fdcx has quit [Ping timeout: 250 seconds]
<MoeIcenowy> (what's CRTC in DRM? is it related to TCON?
fdcx_ has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
ninolein has joined #linux-sunxi
fdcx has joined #linux-sunxi
fdcx_ has joined #linux-sunxi
<wens> CRTC is basically the TCON
<wens> your problem is here: [ 10.326229] sun4i-drm display-engine: No connectors reported connected with modes
<wens> that's because the display mode for "urt,umsh-8596md-t" gets filtered out
<MoeIcenowy> yes...
<MoeIcenowy> after the patch get applied
<MoeIcenowy> CRTC got ok
<MoeIcenowy> fbcon is now 100x30
<MoeIcenowy> but screen is still blank...
<MoeIcenowy> (or I should say it's still white, as lcd panel get disabled after simplefb_lcd exit
<wens> maybe the lcd panel's enable pin is wrong?
Da_Coynul has joined #linux-sunxi
<MoeIcenowy> seems that it haven't correctly get power supply
<MoeIcenowy> I used power-supply = <&reg_dc1sw>;
<MoeIcenowy> but still "panel supply power not found, using dummy regulator"
<MoeIcenowy> (seems that panel got probed before axp223
<MoeIcenowy> oh I got silly, wrote power-supply prop at wrong position (in port@0 of panel)
<MoeIcenowy> But This U-Boot video driver seems to be dependent on some initial status of DE
<MoeIcenowy> and after sun4i-drm mess DE up, it cannot restore it
<wens> yup
<MoeIcenowy> (But I got a display now!
<wens> simplefb just provides a framebuffer, the firmware has to set up the display pipeline
<MoeIcenowy> will your tolerence patch get merged?
<MoeIcenowy> but currently there's a problem... simplefb_lcd do not keep the enable-gpio of panel
<wens> i haven't posted it yet, because i was going to test it on my a23 q8 tablet, and i haven't finished the device tree changes yet
<MoeIcenowy> so after panel is probed, display got white, until tcon is probed
<wens> MoeIcenowy: sounds like a bad initial value :/
<MoeIcenowy> as my panel driver is in zImage, but tcon driver in /lib/modules
<MoeIcenowy> oh if you post it you can add Tested-By me
<wens> MoeIcenowy: can you try changing GPIOD_OUT_LOW to GPIOD_ASIS in panel-simple.c?
<mdsrv> any advices how to build libgl for h3?
<mdsrv> natively?
<wens> libgl as in the mali userspace driver?
<MoeIcenowy> mdsrv: I think you should use LLVMPipe as a fallback now
<MoeIcenowy> it's slow, but at least better than softpipe
<mdsrv> wens: i dont know, im not a specialist
<mdsrv> MoeIcenowy: i just want to debug an error
<mdsrv> from armdebian
<mdsrv> armbian*
<MoeIcenowy> wens: this sounds ok
<MoeIcenowy> but can simplefb handle a panel or its gpio? (As the simplefb really uses the LCD panel...)
<MoeIcenowy> dc1sw is handled well by simplefb driver\
<MoeIcenowy> yes it works :-)
<wens> mdsrv: there is no source for libgl
<wens> MoeIcenowy: i don't think 2 drivers can take the same gpio
<wens> MoeIcenowy: and simplefb takes clocks and regulators because they get turned off by the core if it doesn't
<wens> MoeIcenowy: GPIOs don't get reset
<MoeIcenowy> can simplefb just take panel?
<wens> MoeIcenowy: nope
<wens> MoeIcenowy: simplefb is not part of the drm subsystem
<wens> that is mesa, another gl driver
<wens> for h3, you are probably using the mali driver, which also provides libgl.so
<wens> but i've never used armbian, so i could be wrong
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<mdsrv> i guess it provides
<mdsrv> but
<mdsrv> i want to debug it
<mdsrv> for some reason
<MoeIcenowy> I think mali driver never provide libGL.so
<MoeIcenowy> only libGLESv1_CM, libGLESv2, libEGL
<wens> oh right!
<wens> so then its mesa
Axl_ has joined #linux-sunxi
<mdsrv> wens: This will produce libGL.so and several other libraries depending on the options you have chosen.
<mdsrv> so its mesa
<mdsrv> according to their instructions
<MoeIcenowy> wens: thanks for you indicating :-)
<mdsrv> it was a quote btw
<wens> mdsrv: then you should try to get the source package for the specific version installed in your system
<mdsrv> oh, so taking it from mesa site is not a good idea?
<wens> mdsrv: distributions are free to add patches on top
ganbold has quit [Quit: Leaving]
<wens> mdsrv: so it's best to get a matching source package
ganbold has joined #linux-sunxi
<wens> MoeIcenowy: what's the resolution for your A33 q8?
<MoeIcenowy> 800x480
<MoeIcenowy> use the same panel as your sun5i-a13-q8-tablet dts
<wens> ok, probably only hans has the 1024x600 variant :|
<MoeIcenowy> I will now try Mali
<MoeIcenowy> (will sun4i-drm with xf86-video-modesettings have some performance bonus?
<MoeIcenowy> (compared to simplefb with fbturbo
<mdsrv> hmm
<mdsrv> where can i find source package for mesa?
<MoeIcenowy> mdsrv: from your distribution
<mdsrv> nah
<mdsrv> going to sleep, cannot find anything
<wens> MoeIcenowy: probably not
<MoeIcenowy> testing mripard's xf86-video-armsoc fork
<MoeIcenowy> but got "(EE) _CREATE_GEM({height: 480, width: 800, bpp: 32 buf_type: 0x0}) failed. errno: 22 - Invalid argument" in X log
<wens> MoeIcenowy: check your CMA settings in kernel config
<wens> you need a bigger CMA pool
<MoeIcenowy> but the error is INVAL ...
Axl_ has quit [Ping timeout: 260 seconds]
<MoeIcenowy> oh I didn't enable CMA at all...
<wens> :)
<MoeIcenowy> oh triggered a bug
<wens> O.o
<MoeIcenowy> seems to be some problem in tcon
<MoeIcenowy> when blanking
<wens> i don't think i've seen this
<wens> mripard: ^
<MoeIcenowy> maybe because it's a loosen-clocked panel?
<MoeIcenowy> triggered when I failed to start Xorg with armsoc then switched back to modesetting and restart nodm
<MoeIcenowy> Oh the screen content is sometimes flashing...
<MoeIcenowy> because of panel clock?
_whitelogger has joined #linux-sunxi
Axl_ has joined #linux-sunxi
Axl__ has joined #linux-sunxi
Axl_ has quit [Client Quit]
Axl__ has left #linux-sunxi [#linux-sunxi]
Axl_ has joined #linux-sunxi
leviathanch has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
alexxy[home] has joined #linux-sunxi
alexxy has quit [Ping timeout: 256 seconds]
leviathanch has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
alexxy has joined #linux-sunxi
<MoeIcenowy> wens: there's also a problem
<MoeIcenowy> the fb "blank" is, in fact, white
<MoeIcenowy> oh maybe my dt issue
lkcl has quit [Ping timeout: 244 seconds]
Axl_ has quit [Quit: Ex-Chat]
pg12 has quit [Ping timeout: 244 seconds]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
pg12 has joined #linux-sunxi
Guest91400 has joined #linux-sunxi
Guest91400 has quit [Quit: No Ping reply in 180 seconds.]
<MoeIcenowy> oh the flashing is performance issue :-(
alexxy[home] has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<MoeIcenowy> wens: seems that sun4i-drm is really faster than fbturbo in daily usage
fdcx_ has quit [Remote host closed the connection]
fdcx has quit [Remote host closed the connection]
Axl_ has joined #linux-sunxi
fdcx has joined #linux-sunxi
fdcx has quit [Remote host closed the connection]
alexxy[home] has quit [Ping timeout: 256 seconds]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
[7] has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
<mrnuke> hi, anyone eperienced with NAND around?
alexxy has quit [Ping timeout: 252 seconds]
alexxy has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
alexxy has quit [Ping timeout: 252 seconds]
_whitelogger has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lkcl has joined #linux-sunxi
jrg has quit [Ping timeout: 268 seconds]
JohnDoe_71Rus has joined #linux-sunxi
jrg has joined #linux-sunxi
f0xx has joined #linux-sunxi
lkcl has quit [Ping timeout: 250 seconds]
lkcl has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<KotCzarny> hmm, is that iranian language link proper?
<KotCzarny> 'gpio tutorial'
fdcx has joined #linux-sunxi
petr has quit [Ping timeout: 250 seconds]
petr has joined #linux-sunxi
chomwitt has quit [Ping timeout: 260 seconds]
bugzc has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
netlynx has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
apritzel has quit [Ping timeout: 250 seconds]
jernej has joined #linux-sunxi
reinforce has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
bonbons has joined #linux-sunxi
<wens> MoeIcenowy: did you get vblank time out error?
Putti has joined #linux-sunxi
<MoeIcenowy> wens: yes
quinward has joined #linux-sunxi
<MoeIcenowy> wens: met it again
zoobab has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
f2zubac has joined #linux-sunxi
f2zubac has quit [Client Quit]
scream has joined #linux-sunxi
<MoeIcenowy> wens: are you WIP on A23 drm driver?
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
avph has joined #linux-sunxi
Colani1200 has quit [Ping timeout: 260 seconds]
Colani1200 has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<MoeIcenowy> wens: the vblank timeout error will occur stably when I try to shutdown lightdm
<MoeIcenowy> and then the screen won't display anything
apritzel has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<MoeIcenowy> Net147: ping, how did you get sunxi-mali to work?
Mr__Anderson has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
<MoeIcenowy> Net147: what DDX driver?
<MoeIcenowy> has sun4i-drm GEM codes entered mainline kernel?
<MoeIcenowy> or I should cherry-pick them?
<MoeIcenowy> (My HEAD is 4.9-rc plus several patches to get panel to work
<Net147> MoeIcenowy: no. see my linux branch for the changes.
<MoeIcenowy> net147: when will you send out your patches?
<Net147> MoeIcenowy: the GEM patches are mripard's ones
<MoeIcenowy> yes I saw them
<MoeIcenowy> Is the patches related fb useful? (As I know, xf86-video-armsoc uses KMS
<Net147> MoeIcenowy: I prefer to use fbdev Mali blob. You don't need for X11.
<MoeIcenowy> you have fbdev blobs?
<Net147> MoeIcenowy: r3p2
<MoeIcenowy> so old
<MoeIcenowy> how can it work on r6p0
<Net147> MoeIcenowy: I ported r3p2 to mainline
<MoeIcenowy> but r3p2 is unredistributable
<Net147> MoeIcenowy: yes, that is why I want r6p0
<MoeIcenowy> https://github.com/net147/sunxi-mali/ is r6p0, right?
JohnDoe5 has joined #linux-sunxi
<Net147> MoeIcenowy: master branch is r6p0, I have branches for r3p2 and others
JohnDoe_71Rus has quit [Ping timeout: 250 seconds]
Da_Coynul has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
<Net147> MoeIcenowy: you need CONFIG_CMA=y, CONFIG_CMA_SIZE_MBYTES=256, CONFIG_DMA_CMA=y for X11 otherwise buffer allocations in sun4i-drm may fail
<MoeIcenowy> my tablet have totally 512M mem
<MoeIcenowy> allocate 256M for CMA is crazy
<MoeIcenowy> :-)
<KotCzarny> it doesnt preallocate it
<KotCzarny> so when not used it doesnt take it away from system
<KotCzarny> some mem allocations are forbidden in that area though
<MoeIcenowy> thanks :-)
avph has joined #linux-sunxi
dh1tw has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
<MoeIcenowy> Net147: thanks! I got NTC's blob running on my A33 tablet
<MoeIcenowy> running glmark2-es2 now
<KotCzarny> tkaiser, and others too: nice explanation about clocking chips to higher freqs: http://electronics.stackexchange.com/questions/13873/why-exactly-do-chips-start-malfunctioning-once-they-overheat/156130#156130
<KotCzarny> and the effect of such
AneoX has joined #linux-sunxi
<AneoX> I'm trying to reduce the boot time of my board by skipping u-boot and trying to load a compressed kernel directly from the u-boot SPL. Is there a way to do such thing? If so how? I am using sunxi-kernel + script.bin. Thx
<AneoX> Board with A20
<KotCzarny> you can just change uboot config (disable network, usb, delays, etc)
<KotCzarny> easier and more configurable
<MoeIcenowy> Oh my A33 tablet scores only 18 in glmark2-es2
<MoeIcenowy> unbelievably low score
<KotCzarny> MoeIcenowy: retry with software rendering? :>
<MoeIcenowy> retrying
<MoeIcenowy> seems to be lower (I use LLVMpipe)
<apritzel> AneoX: as KotCzarny said: don't go there, there be dragons
<AneoX> (disable network, usb, delays, etc) done, but it spends about 2 sec
<KotCzarny> what does it do during those 2s?
<KotCzarny> keep in mind loading kernel takes some time
<KotCzarny> this os either way
<KotCzarny> *or
<MoeIcenowy> KotCzarny: Seems that compare LLVMpipe and GPU with glmark2-es2 is not a good idea
<MoeIcenowy> for some simple scenes LLVMpipe can work
<MoeIcenowy> but for difficult scenes LLVMpipe is a disaster
<KotCzarny> MoeIcenowy: unless cpu is more free with gpu offload, then it could be a win
<AneoX> spl boots uboot, then kernel. My kernel boots 2.5sec. and app about 2, totaly >6. if remove u-boot, it will be ok, 4 sec
<MoeIcenowy> AneoX: nope
<MoeIcenowy> the 2 sec will go into SPL rather than U-Boot.
<KotCzarny> and into loading files
<MoeIcenowy> LLVMpipe got a 12.
<MoeIcenowy> AneoX: for these kind of serious scenes, try to reduce your kernel
<AneoX> 1,6mb, removed all unnecesary
<KotCzarny> add li-ion backup and suspend to ram?
<AneoX> board already in production, no battery
<KotCzarny> make v2 or ++ version
<KotCzarny> ;)
<AneoX> i think, its possible to reduce u-boot time at least to 1 sec, because loading files is fast 43068 bytes read in 87 ms (483.4 KiB/s) script and kernel 1620832 bytes read in 247 ms (6.3 MiB/s)
<apritzel> does anyone know where to read the SoC ID from?
<KotCzarny> uncompressing kernel? using lzo?
<apritzel> (not the SID)
<apritzel> sunxi-fel seems to get it from some special FEL command
<MoeIcenowy> AneoX: but SPL MMC driver is weaker than U-Boot MMC driver
<AneoX> KotCzarny: not sure, i moced to sunxi-uboot, its faster than mainline
<apritzel> jumping from a plane without a parachute is faster than having one ;-)
<KotCzarny> AneoX: you might also pursue some cold hibernation predefined state?
<KotCzarny> instead of booting every time?
<AneoX> please advise how to try it
<KotCzarny> i dont know if swsusp has an option not to delete hibernation state after resuming, in tux-on-in has such option, but it might be not compatible with sunxi
<KotCzarny> *tux-on-ice
<apritzel> I doubt that suspend brings anything here, especially with this slow I/O on sunxi SoCs
<KotCzarny> apritzel: booting takes time and same slow i/o too
<apritzel> but how is suspend/resume supposed to help if U-Boot is the time hog?
<KotCzarny> im thinking about post-uboot load time
<apritzel> didn't he say 2 seconds?
<KotCzarny> he just meant spl+uboot phase, im sidetracking possible os optimizations (i dont know what os he uses though)
<apritzel> now how long does it take the read the 512MB or so from MMC storage into DRAM?
<KotCzarny> apritzel: compression + not loading empty pages makes it a lot less
<AneoX> no os, simple busybox
<KotCzarny> ah, then nvm
<MoeIcenowy> is mali blob from NextThingCo redistributable?
<miasma> AneoX: did you try different kernel compression options
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
\\Mr_C\\ has joined #linux-sunxi
<AneoX> miasma: No
<miasma> AneoX: if the read speed is 6.3 MB/s, try lz4 for kernel & initramfs. it might be the fastest on a20
<AneoX> Ok, i will try, thx. Do you think it really increase time with 1.5mb kernel?
<miasma> lz4 is fastest to decompress unless you previously used an uncompressed kernel
<miasma> but it might not make a huge difference
<KotCzarny> but might if he used default gzip
<KotCzarny> are kernel compression algos multicore?
<miasma> i tested these on x86 and they basically didn't make any difference, but on arm if the uboot is slow at reading kernels from sd/network, you might want to use xz, because it reduces the kernel's size. otherwise a fast algo
<miasma> e.g. on my rpi the read speed is something ridiculous like 200 kB/s
<AneoX> sunxi kernel not lz4 option, gzip, lzma, xz, lzo
<KotCzarny> try them all
<KotCzarny> it's 5-10 minutes of work
<miasma> iirc, lzo is the second best
<AneoX> seems sunxi u-boot not workings with lzo
apritzel has quit [Ping timeout: 256 seconds]
jernej has quit [Ping timeout: 250 seconds]
gianMOD has quit [Remote host closed the connection]
cnxsoft has quit [Quit: cnxsoft]
quinward has quit [Quit: WeeChat 1.5]
station has quit [Ping timeout: 250 seconds]
gianMOD has joined #linux-sunxi
dlan has quit [Ping timeout: 260 seconds]
dlan has joined #linux-sunxi
Axl_ has quit [Remote host closed the connection]
chomwitt has joined #linux-sunxi
station has joined #linux-sunxi
PaceyIV has joined #linux-sunxi
PaceyIV has quit [Client Quit]
Axl_ has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
tkaiser has joined #linux-sunxi
jernej has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
kaspter has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
The_Loko has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
jernej has quit [Ping timeout: 244 seconds]
jernej has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
quinward has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
avph has joined #linux-sunxi
lamer14784472321 has joined #linux-sunxi
JohnDoe5 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
lamer14784472321 has quit [Client Quit]
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> wens: thanks
<MoeIcenowy> wens: oh, have you tried to add cpufreq support to a23/33 tablets?
<MoeIcenowy> (I think they're worth implementing cpufreq, at least for power management
<MoeIcenowy> (although mainline kernel still plays badly in pm
arete74 has quit [Ping timeout: 265 seconds]
<wens> MoeIcenowy: the cpufreq-dt platform device is already registers for all SoCs
<MoeIcenowy> yes
<MoeIcenowy> but after adding opps
<wens> MoeIcenowy: you just need to find a suitable set of OPPs and add it to the DT
<MoeIcenowy> I found some serious problems
<MoeIcenowy> ok I will try now
<wens> and the regulator and clock
<MoeIcenowy> maybe I cannot reproduce them, and I will get glad ;-)
arete74 has joined #linux-sunxi
<wens> if there are issues it might be the cpu pll
<MoeIcenowy> do a23/33 needs different opp?
<wens> MoeIcenowy: no idea
<MoeIcenowy> ok now it's the time to refer to FEXs
tkaiser has quit [Ping timeout: 268 seconds]
<wens> MoeIcenowy: do you have gmail account? i can share the spreadsheet mripard and i used for OPPs
<wens> it has A23 already
<MoeIcenowy> icenowylin@gmail.com
<MoeIcenowy> thanks ;-) got it
<mdsrv> nah
<mdsrv> i dont know
<mdsrv> how to build mesa ;<
<MoeIcenowy> but it's only a rearrangement of https://github.com/linux-sunxi/sunxi-boards ;-)
<mripard> MoeIcenowy: qschulz has been working on it for the past weeks, he has something that should work on the A33
<mripard> thermal throttling included
<wens> MoeIcenowy: a table is easier to look at than a whole bunch of files :)
<wens> mripard: yay!
<MoeIcenowy> with GPADC-driven THS?
<mripard> yes
<wens> mripard: fyi after i get all the audio codec stuff out, and a23 drm done, i'm going to look at psci for a80
<MoeIcenowy> but on his github, no opp is added
<mripard> MoeIcenowy: I'm not sure he pushed it yet
<MoeIcenowy> he has branches with proper a33 ths support
<MoeIcenowy> but no cpufreq support
<mripard> MoeIcenowy: I'm not sure he pushed it yet
<mripard> :)
<MoeIcenowy> and when 4.8-rc I tested a33 ccu with opps
<MoeIcenowy> cpu pll got wrong
<wens> i guess we'll see them soon enough
<MoeIcenowy> oh got opp table
<MoeIcenowy> he pushed it
<MoeIcenowy> but didn't split commit
<mripard> wens: that would be awesome, what are you using to test the big cores ? IKS or EAS ?
<wens> mripard: plan is to bring all the cores up first :)
<wens> turning them off is actually easier than turning them on
<wens> code wise
<MoeIcenowy> is A80 still produced and sold? ;-)
<wens> MoeIcenowy: no idea, but i spent some money on 2 boards, and i would like to at least use them for something worth the money
<MoeIcenowy> yes ;-) A80 boards are expensive
<MoeIcenowy> I joined the QQ group by CubieTech for Cubieboard support, and known a second-hand CC-A80 is still RMB ¥500
<MoeIcenowy> (~ $80)
<MoeIcenowy> but A80 do disappeared from allwinnertech.com
<wens> MoeIcenowy: about the cpu pll gone wrong, is it the register values are wrong or just a glitch?
<MoeIcenowy> I do not know register values
<wens> if the register values don't line up with the datasheet, then it needs fixing
<MoeIcenowy> but the cpuinfo_cur_freq become 32000 (or 24000... I forgot it)
<wens> ok, cpu clock is missing CLK_SET_RATE_PARENT ...
<MoeIcenowy> I will try it again now
<MoeIcenowy> mripard: do you have any idea about the vblank timeout problem reported by me?
<mripard> where did you report it ?
<MoeIcenowy> in this irc channel ;-(
<MoeIcenowy> the error will appear when I try to shutdown X server
<MoeIcenowy> or run X server for a long time (~10min)
<wens> MoeIcenowy: for the cpu clock, add CLK_SET_RATE_PARENT to the flag on https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun8i-a33.c#n173
<mripard> I was away most of the weekend, what is the issue?
<MoeIcenowy> and then screen got blank, nothing displayed
avph has quit [Ping timeout: 260 seconds]
<mripard> when you do what? on what SoC / board?
<MoeIcenowy> A33 Q8 Tablet
<MoeIcenowy> DDX driver tried both armsoc and modesetting
avph has joined #linux-sunxi
apritzel has joined #linux-sunxi
<MoeIcenowy> wens: is use CLK_CPUX for cpu0 clocks proper on a23/33?
<wens> MoeIcenowy: what do you mean
<MoeIcenowy> the clock that cpufreq-dt driver modifies
<MoeIcenowy> ok reproduced the issue
<MoeIcenowy> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is 24000 ;-)
<MoeIcenowy> will try your hack
<wens> yes
<MoeIcenowy> how to add CLK_SET_RATE_PARENT ? use 'CLK_IS_CRITICAL | CLK_SET_RATE_PARENT' ?
<wens> yup
apritzel has quit [Ping timeout: 250 seconds]
<MoeIcenowy> now trying (scp speed when CPU is at 24MHz ;-)
<MoeIcenowy> wens: ok the system now stucks
<MoeIcenowy> kind of mystery clk-related bugs ;-)
<wens> ugh, probably the pll is driven too high
honx has quit [Ping timeout: 256 seconds]
<wens> you can try porting this to a33 and see if it works
<MoeIcenowy> I think the dmesg info did no help on debuging this kind of bug
<MoeIcenowy> ok from my perspective of view you the ccu driver writers are magicians
<MoeIcenowy> (oh the stucking problem exists also in old clk driver ;-(
<wens> MoeIcenowy: nah, i've just been around longer than you have :p
<wens> and i did the a31 ccu driver, which crashed the first time, hence the fix above
<MoeIcenowy> wens: why do pll1 called "pll_cpu" in a31, but "pll_cpux" in a33?
quinward has quit [Quit: WeeChat 1.5]
<MoeIcenowy> wens: ok now it works!
<MoeIcenowy> should I push these patches?
<MoeIcenowy> mripard: ^
vagrantc has joined #linux-sunxi
honx has joined #linux-sunxi
<wens> MoeIcenowy: ugh, follows the datasheet i guess
<wens> MoeIcenowy: you should post the ccu fix :)
<MoeIcenowy> I mean ccu fix
<MoeIcenowy> and I will try to understand why it works
<MoeIcenowy> should I push opps?
avph has quit [Ping timeout: 250 seconds]
<wens> you and qschulz could probably talk about it?
<wens> or you could just post it
<mdsrv> wens: i think
<mdsrv> im too dumb
<wens> i guess its really up to you
<mdsrv> to build libgl
<mdsrv> i dont know where i can get libdrm_intel
<wens> MoeIcenowy: you might want to use OPPv2 if you aren't already
<mdsrv> so sad
<MoeIcenowy> What's OPPv2?
<wens> MoeIcenowy: v2 of the OPP bindings, see Documentation/devicetree/bindings/opp/opp.txt
<wens> time for bed
<mdsrv> no
<mdsrv> tell me sth
<mdsrv> about libgl
<MoeIcenowy> mdsrv: libgl is from Mesa
<MoeIcenowy> http://www.linuxfromscratch.org/blfs/view/svn/x/mesa.html have some instructions, but for x86
<MoeIcenowy> you can reduce drivers to suit it for arm
<mdsrv> yeah, and the question is
avph has joined #linux-sunxi
<mdsrv> how to make it to be silent on libdrm_intel stuff
<MoeIcenowy> just do not build i9.5 drivers
<mdsrv> i dont build anything, just run configure
<mdsrv> tell me how not to build these drivers
diego71 has quit [Remote host closed the connection]
netchip has joined #linux-sunxi
<mripard> MoeIcenowy: qschulz already has these patches obviously
<mripard> so, yeah, you can talk to him, or push them
<mripard> they're going to be pushed either way
<mripard> for you warning, it happens when you do what?
<mripard> nothing?
<MoeIcenowy> mripard: you mean ccu patches?
<MoeIcenowy> I think his opps too radical and dangerous :-(
<mripard> this is not a oops, but a warning
bananapi-debian has joined #linux-sunxi
<mripard> and again, when does that happen?
<MoeIcenowy> mripard: the screen cannot display anything
<MoeIcenowy> and if at that time there's Mali program running, the program will fail
kaspter has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<bananapi-debian> Hi! Anybody have an idea why my keyboard doesn't work on a newly debootstrapped Debian Jessie installation? I can see the login prompt on the screen (tty1), but the keyboard doesn't seem to do anything. My guess is it has something to do with systemd, but I just can't figure it out. U-Boot is 2016.7 and Kernel is 4.4.30. The keyboard works in U-Boot.
<bananapi-debian> And the same kernel, u-boot and kernel commandline (console=tty1) work on an older debootstrapped Debian Wheezy system which still uses inittab.
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mripard> MoeIcenowy: you still haven't said what triggers that warning, when you start X? When you load a module?
<KotCzarny> systemd is evil and should be removed
<mripard> usually, when it comes up is when you don't have a valid mode, but that should way earlier
<bananapi-debian> Btw. I can ssh into the system and the logs say "systemd[1]: Started Getty on tty1." The screen output is there, but keyboard input seems to be ignored.
<KotCzarny> check with lsusb if kb is detected
<KotCzarny> or with dmesg
bugzc has joined #linux-sunxi
<bananapi-debian> KotCzarny: The keyboard seems to be recognized, I see the usb events when I plug it out an in, and it also loads "usbhid: USB HID core driver" after recognizing the usb device on boot
<KotCzarny> then just remove systemd (correctly) and be done
<KotCzarny> it's still possible to do in jessie
<bananapi-debian> KotCzarny: Is there another way to verify the usb device is actually set up as a HID device?
<KotCzarny> ls /dev/input/ ?
<KotCzarny> or cat /proc/bus/input/devices
<KotCzarny> kb should have kbd in handlers line
<bananapi-debian> KotCzarny: I know it's possible. But I also know it's possible to get it working someway. I have another board upgraded from Wheezy to Jessie (incl. systemd). And there the keyboard works, but it also took over the old inittab from Wheezy. I might just copy that, but I thought there must be another way if that's not used by default anymore.
<KotCzarny> trust me. systemd IS evil
<KotCzarny> trying to make it work is just inflicting more future pain
<MoeIcenowy> mripard: when I stopped X
<MoeIcenowy> or have X running for some minutes
<MoeIcenowy> and I misread your sentences
<MoeIcenowy> sorry :-(
<TheLinuxBug> <KotCzarny> trust me. systemd IS evil - Preach on my borther, preach on! ;)
<TheLinuxBug> SysV 4 life
<KotCzarny> sanity4life!
<KotCzarny> systemd is insane/braindamaged by design AND implementation
gianMOD has joined #linux-sunxi
<TheLinuxBug> indeed!
<bananapi-debian> KotCzarny: Well, I don't engage in philosophical debates over init systems. Honestly, I don't care much. On a couple of systems, I use Debian's default choice of systemd without any issues. And frankly, while sticking to sysvinit works well for the time being, you never know what dependencies they add in the next release. So the question to me really is, how to configure the console properly and I'm sure some sunxi folks h
<KotCzarny> bananapi-debian: its not philosophical. CODE is bad, buggy and broken
<bananapi-debian> That being said, while I assume it's a systemd related issue, I'm not sure. It might be something different that I'm missing
<mripard> MoeIcenowy: then, this warning happens when the vblank interrupt doesn't report the event
<mripard> MoeIcenowy: so there's probably something wrong in our CRTC disable code path
<MoeIcenowy> mripard: is it because I'm not use the very precise clock?
<KotCzarny> you can cat /dev/input/eventX device and type something on the kb
<MoeIcenowy> (I cherry-pick the patch from wens
<mripard> KotCzarny: because init scripts are so much better from that aspect.
<KotCzarny> if it outputs anything then system/device works, just gets broken in the software
<KotCzarny> mrpipard: because i can trim/modularize/modify my os to my liking. which is being locked in with systemd
<KotCzarny> systematically and progressively
<MoeIcenowy> KotCzarny: why do you say "locked" ?
valkyr1e has quit [Ping timeout: 256 seconds]
<mripard> MoeIcenowy: probably not, if it was that you would see it very early on
gianMOD has quit [Ping timeout: 260 seconds]
<mripard> but without the rest of the logs it's hard to tell
<bananapi-debian> KotCzarny: I don't have a /dev/input* .... I'll check if I see that on another machine
<MoeIcenowy> mripard: The panel clock issue used to prevent me from using sun4i-drm until I used wens's patch
<mripard> KotCzarny: that's BS. You can tweak any unit files with systemd
valkyr1e has joined #linux-sunxi
<mripard> KotCzarny: and while I might agree that some aspects of systemd are bad
<mripard> KotCzarny: some long standing issues with init scripts were much worse
<MoeIcenowy> systemd can even have "overlay" changes in /etc for units in /lib
<mripard> like the fact that all distros had to come up with their own init scripts, that would be broken in very subtle and different way
<KotCzarny> cant find the link in a quickie, let me search it
<mripard> without any way to share them
<mripard> see https://lwn.net/Articles/701549/ for a good example where systemd shines
<mripard> and yes, the implementation might suck
<mripard> but we don't really have any alternative
<MoeIcenowy> yes as a distro maintainer systemd freed me from maintaining init scripts ;-)
<KotCzarny> simplicity for distro maintainer != security/sanity for the user
<mripard> indeed
<KotCzarny> see the bananapi-debian for example
<bananapi-debian> Ok... I gotta prepare some dinner now.. but I'll leave the chat open, so if anybody has more ideas what I might check or look her, I'll catch on later. Thanks
<MoeIcenowy> but systemd is now becoming a standard of different distros
<KotCzarny> bananapi-debian: it might be /dev/event/inputX
<KotCzarny> replace X by proper number
<mripard> now you know why distros maintainers and applications developpers want to ship something that just works and that allows them to code on something meaningful instead of a dumb broken and limited shell script
<MoeIcenowy> in our distro this is joked to be "Lennart Standard Base" ;-)
<KotCzarny> limited?
<mripard> limited.
<KotCzarny> in what way shell scripting is limited?
<MoeIcenowy> KotCzarny: at least it cannot support cgroups
<mripard> how do you monitor that the application is still running, and respawn it afterwards ?
<MoeIcenowy> so programs can escape the monitering of shell scripts by forking twice
<KotCzarny> uh, inetd ?
<mripard> how do you say something like "spawn those 5 different services and trigger a LED depending on the outcome" ?
<KotCzarny> some other daemon watcher?
<KotCzarny> i can script/code it for a multitude of ways
<MoeIcenowy> KotCzarny: inetd has lost its value in systemd world, as systemd's *.socket can replace it
<mripard> those are very standard use case
<MoeIcenowy> mripard: do you have any ideas of possible fix of my drm problem?
<MoeIcenowy> and did you met it on SinA33?
<mripard> MoeIcenowy: I didn't, but I'm not sure I ever disabled it
willmore has quit [Ping timeout: 245 seconds]
<mripard> can you enable drm.debug and give all the logs?
<MoeIcenowy> of course, can it be done by add "drm.deubg=1" in bootargs?
<MoeIcenowy> oh it's 0x3f
<MoeIcenowy> mripard: the problem *won't* occur in only fbcon, neither with weston, only with X it occurs
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<mripard> MoeIcenowy: that would be interesting to get an idea why
willmore has joined #linux-sunxi
diego__ has joined #linux-sunxi
diego__ is now known as diego71
* MoeIcenowy go to bed, will read messages tomorrow
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
The_Loko has quit [Quit: Leaving]
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
dh1tw has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
netlynx has quit [Quit: Ex-Chat]
Da_Coynul has joined #linux-sunxi
<MoeIcenowy> mripard: another problem, after I stoped lightdm, even fbcon is not usable, as the whole panel is disabled (even the backlight is killed)
avph has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<mripard> MoeIcenowy: all the logs, from boot please :)
<mripard> fbcon should still be here, but running on drm
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
Andy-D has quit [Quit: Alive/Dead]
Andy-D has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 260 seconds]
gianMOD has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
Axl_ has quit [Ping timeout: 252 seconds]
dh1tw has joined #linux-sunxi
<mdsrv> hey
<mdsrv> i have a question
<mdsrv> if h3 does not support opengl, this means all opengl stuff will run with sw rendering?
<KotCzarny> yup
<mdsrv> and u mean that opengl es is not the same as opengl?
<KotCzarny> yup
<KotCzarny> see glshim project
<mdsrv> ok
<tkaiser> mdsrv: What is your use case? Running benchmarks or real stuff?
<KotCzarny> tkaiser: did you see the link about overclocking and chip aging?
<mdsrv> i want to find out why my SDL2 app does not work when mesa with hw support is installed
<tkaiser> KotCzarny: yes
<bananapi-debian> Ok, I'm back. So about my keyboard problem...
<mdsrv> with libgl-mesa-swsomething it works ok, but a bit laggy
<KotCzarny> tkaiser: that means 1296 might not be exactly best idea
<tkaiser> KotCzarny: Then use 480 or whatever you like
<KotCzarny> just saying, because you care about reliability, and having sudden errors due to oc/age isnt good
<KotCzarny> yet, its default in armbian
<tkaiser> KotCzarny: C'mon, it's default for the few H3 devices with SY8106A and it's known to work. If anyone does number crunching on a H3 device he's dumb anyway.
<miasma> can't they just install bigger heatsinks
<KotCzarny> 'known to work' isnt the best argument here, and while i agree those boxes are mostly hobbyist, you were adamant on stability/reliability stance
<KotCzarny> miasma: its not about temperature, but higher mhz
<miasma> ok
<bananapi-debian> I was kinda stupid :( After wondering why my keyboard would not show up in /dev/input/* (thanks @KotCzarny!), I decided to go to the basement and pull out a different keyboard. And with that other keyboard, everything works. So, it turns out there is no problem with the console/tty configuration or systemd at all.
<bananapi-debian> I'm surprised that the other keyboard worked in U-Boot but not in Linux, but I suspect it doesn't register as a normal USB HID device and require some magic kernel module. I'll look into that. But for now, I'm glad to know that the installation itself is fine.
<KotCzarny> plug it into pc and see what modules load / msgs show up in dmesg
<bananapi-debian> KotCzarny: Yeah, I was about to do that now ;)
<tkaiser> KotCzarny: So you suggest 480 MHz max cpufreq? Or 720? Or 960?
<KotCzarny> nope, 1200 (as suggested by allwinner sdk) with easy overclock/downclock by user choice
<tkaiser> KotCzarny: Please do a 'cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state'
<KotCzarny> my boxes are mostly idle
<KotCzarny> at least when not compiling
<tkaiser> KotCzarny: Great, so they're at 480 MHz and not 1296 all the time.
<KotCzarny> but my usecase might be different than other users, and im not the distro maintainer which is what you are
<KotCzarny> my choices only affect me and my boxes, yours might affect thousands
<KotCzarny> and it might not even show during lifetime (ie. before being replaced by faster board next year)
<mdsrv> tkaiser: real stuff
<tkaiser> KotCzarny: Armbian does also slightly undervolt the SoC so your argumentation fails completely. This undervolting happened by accident (communication issues between Igor and me) but we left it and were curious whether reports come in about undervoltage issues. We had 2 out of thousands so far
<KotCzarny> tkaiser: nope. its not about voltage/temperature at all. its about aging because of higher freq
<tkaiser> KotCzarny: To be honest I really don't care about this. If someone wants to do number crunching on a $15 SBC then he should do and maybe buy a new SBC after 3 instead of 5 years.
<tkaiser> Since 'aging' is an issue
<bananapi-debian> KotCzarny: The keyboard in question seems to require the HIDRAW module, which is not included in the kernel. Good to know. Now I can actually start doing something useful ;)
<KotCzarny> at least it's supported at all
rah has quit [Quit: leaving]
rah has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yann-kaelig has quit [Quit: Leaving]
rah has quit [Quit: leaving]
rah has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
f0xx has quit [Ping timeout: 244 seconds]
AneoX has quit [Ping timeout: 260 seconds]
bananapi-debian has left #linux-sunxi [#linux-sunxi]
dr1337 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leviathanch has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
station has quit [Ping timeout: 260 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Ping timeout: 244 seconds]
station has joined #linux-sunxi
gianMOD has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
gianMOD has quit [Ping timeout: 260 seconds]
Mr__Anderson has quit [Quit: Leaving.]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
netchip has quit [Ping timeout: 260 seconds]
vagrantc has joined #linux-sunxi
dr1337 has joined #linux-sunxi
dh1tw has joined #linux-sunxi
dr1337 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iamfrankenstein has quit [Quit: iamfrankenstein]
dr1337 has joined #linux-sunxi
dr1337 has quit [Client Quit]
dr1337 has joined #linux-sunxi
dr1337 has quit [Client Quit]
dr1337 has joined #linux-sunxi
scream has quit [Remote host closed the connection]
jernej has quit [Ping timeout: 244 seconds]
popolon has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
paulk-collins has quit [Quit: Leaving]
yann-kaelig has joined #linux-sunxi
<yann-kaelig> Hi. Do you know if this baseboard is compatible with cubieboard 2 https://store.iotllc.com/images/D/IMG_2362_Small.JPG
stk has joined #linux-sunxi
AneoX has joined #linux-sunxi
cptG_ has joined #linux-sunxi