<tkaiser>
We also disabled voltage switching for the Orange Pi One for now and limited max cpufreq to 1104MHz until thermal issues are really resolved on this board or in this combination u-boot/kernel
iamfrankenstein1 has joined #linux-sunxi
pitillo has joined #linux-sunxi
<pitillo>
hello, I've been reading about sunxi-mali problems/error in the logs, but I'm not sure why I'm getting problems in the test step. I've checked that mesa3d is built without GLESvx and EGL support and when the test file is built, it's only linked with libEGL.so (I can't see any other related lib linked, like GLESvx, is this normal?)
<pitillo>
mali, mali_drm and ump modules are loaded, devices (mali and ump) have right permissions, and there is no way to get the test file working. I'm getting the error Error: eglInitialise failed!)
pietrushnic`away has joined #linux-sunxi
<pietrushnic>
hi all, I enabled rtl8723bs with sunxi-3.4 for my custom board but have huge difference in upload (60Mbps) vs download (100Kbps), any idea what can be the problem or how to approach debugging ?
<pietrushnic>
board is A20 based very similar to A20-OLinuXino-MICRO, wifi is over SDIO (SDC3)
libv has quit [Ping timeout: 248 seconds]
libv has joined #linux-sunxi
<hp197>
Device Tree question
<hp197>
On the 3.4 kernel, you could use gpio_pin_X in the fex to enable gpio's
<hp197>
When I enabled PI14, I got automaticly irq connected in the kernel (e.g. edge file was available in /sys/class/gpio/gpioxxx/)
<hp197>
Now with device tree in mainline kernel, can I still have my gpio decalred as "regular" input pin in the DT, or do I explicitly need to declare it as irq?
<hp197>
> allwinner,function = "irq";
libv has quit [Ping timeout: 250 seconds]
libv has joined #linux-sunxi
<hp197>
The reason for this question, I have found a kernel driver who expects a GPIO in the device tree and creates a irq out of it... If I declare the GPIO as irq in the DT the module doesn't seem to find the pin
mzki has joined #linux-sunxi
<hp197>
if I declare the pin as gpio_in the kernel function gpio_to_irq doesnt seem to work (it doesnt seem to get any irq handler and I doubt the mux is set in the right direction)
<apritzel>
montjoie: just downplay your code in the cover letter or commit message ;-)
<apritzel>
montjoie: I just briefly looked over it and the code looks reasonable enough to be released
<apritzel>
at least good enough for RFC
<montjoie>
I will made a final test tonight for be sure that I wont forgot a debug that break all, and release it after
<hp197>
still find the pin numbering in DT configusing though... DT = alphabet# & pin# gpio # in linux = alphabet# X 32 + pin#
<hp197>
PH14 = H = 8th letter in alphabet = 8 X 32 + 14 = gpio270 in the kernel
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
hp197: I guess this is more of an issue with the sysfs interface, right?
<apritzel>
because it exposes the kernel internal numbering
<apritzel>
which usually you don't care about because it's, well, kernel internal
<hp197>
yeah, I guess its not the fault of DT itself, more the kernel
<hp197>
hopefully will get better in the future
JohnDoe4 has joined #linux-sunxi
<apritzel>
I agree it would be nice to have a mapping functionality between reasonable numbers for instance used in the manual (like PH14) to kernel internal numbering
<hp197>
though, as soon you know how the number correlates to the pins, it is decent enough to work with...
<apritzel>
I know ;-)
<hp197>
anyway, enough bitching :p
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
hipboi has quit [Quit: This computer has gone to sleep]
hipboi has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 244 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
ssvb has joined #linux-sunxi
Ueno_Otoko has quit [Ping timeout: 244 seconds]
KotCzarny has quit [Ping timeout: 255 seconds]
doppo has quit [Ping timeout: 240 seconds]
doppo has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
mzki has quit [Quit: leaving]
paulk-collins has joined #linux-sunxi
<pitillo>
hello, I've been reading about some sunxi-mali problems/errors in the irc channel logs, but I'm not sure why I'm getting problems running the test file. I've checked that mesa3d is built without GLESvx and EGL support and when the test file is built, it's only linked with libEGL.so, the one installed from sunxi-mali (I can't see any other related lib linked, like GLESvx, is this normal?)
<pitillo>
mali, mali_drm and ump modules are loaded, devices (mali and ump) have right permissions, and there is no way to get the test file working. I'm getting the error Error: eglInitialise failed!)
<ssvb>
pitillo: what kind of allwinner hardware are you using?
<ssvb>
and which kernel?
<ssvb>
also framebuffer or x11?
<pitillo>
ssvb: I'm trying to get it working on the orangepipc (h3) with 3.4.39 under x11
<ssvb>
the use of mali drivers on h3 is a little bit untested
<ssvb>
which version of the mali kernel driver is used in your kernel?
<pitillo>
yes, I'm using the same method with a cubieboard (A10) which seems to work right
<pitillo>
ssvb: a window manager using GLESvX could be one for example... btw, should be enought to use mesa3d software render and GL/GLES stuff then? (sunxi-mali and fbturbo for X)
<pitillo>
tkaiser: thank you, I'll check it out too
<tkaiser>
It's based on ssvb's work and IIRC yann|work was also after the same stuff like you now
<pitillo>
and why not merge changes in one branch? incompatibilities?
<tkaiser>
No one wants to maintain 3.4.x any more ;)
<tkaiser>
ssvb already asked on the linux-sunxi mailing list. No answers IIRC
<pitillo>
too many forks... and a big lack of knowledge...
<tkaiser>
Just in case you want to use this for something productive. Applying the updates up to 3.4.110 doesn't hurt. And then there are some tweaks regarding display and network
<tkaiser>
But if it's just about getting mali drivers working then you can happily ignore all of this
<pitillo>
something productive... nothing serious, just for fun tkaiser
<tkaiser>
Good
<pitillo>
get mali drivers working could be good too, but it's messy
<pitillo>
building a custom kernel is the first step... next things will come later. At the moment I'm not using the toy for nothing special
apritzel has quit [Ping timeout: 248 seconds]
Turl has quit [Remote host closed the connection]
Turl has joined #linux-sunxi
Nacho has quit [Ping timeout: 276 seconds]
<tkaiser>
ssvb: Good news! I've been too confused yesterday and mixed thermal results from Orange Pi PC with One :\
<tkaiser>
I made some tests now using the Orange Pi One with heatsink, identical kernel and one time boot0 and the other mainline u-boot
<tkaiser>
In the fex file I switched off switching between higher and lower voltage so all tests happened with the same Vcore voltage (I still assume close to 1.3V)
<tkaiser>
While the temperatures with mainline u-boot are reported the same 10¡C lower as you reported interestingly throttling and cooling states behaved more ore less the same