<Alex1269>
Tried fresh stage/sunxi-3.4 on cubie... Still edid/fb problems - "Division by zero in kernel" in fb_videomode_pixclock_to_hdmi_pclk
eebrah has joined #arm-netbook
zaxz has joined #arm-netbook
zaxz has quit [Client Quit]
<mnemoc>
mv "$f" $"x" ...... /me cries after seeing half his music collection destroyed by a typo
<mnemoc>
Alex1269: report it on the mailing list please
vgrade has joined #arm-netbook
<Alex1269>
Ok... i'll do this. mnemoc, I confirm subsys_initcall problem with gpio-sunxi - this is because sys_config stuff initialized later at fs_initcall level. Is there reasons against doing this in arch level ?
<mnemoc>
not really
<mnemoc>
please send the fixes :)
<Alex1269>
Also I didn't found CONFIG_GPIO_SYSFS=y and CONFIG_EXPERIMENTAL=y options in configs needed to export gpios to sysfs
<Alex1269>
Ooops. My fault, patches doesn't contain CONFIG_EXPERIMENTAL (our gpiolib version want this for sysfs)
<mnemoc>
ok. I'll re-run defconfig generation with CONFIG_EXPERIMENTAL=y CONFIG_GPIO_SYSFS=y
<Alex1269>
I'll try to move sys_config init to arch level
<Alex1269>
I have a patch adding a pull support to gpiolib/gpio-sunxi. What do you think - is possible to change gpiolib ?
<mnemoc>
br-: "in raid1 we trust" .... until the idiot deletes the stuff
<br->
:(
<br->
i drank too much sugar when younger, eventually learned to back things up, at least bi-monthly or so
<br->
rm rf foo.*.txt! enter!enter!enter! this rm take too long!! slow computer *slurrrrp* *burp* wtf wtf! slow computer! ctrl+c!!!! <half a missing homedir>
<mnemoc>
Alex1269: as it will be controversial, let's wait a bit with the pull support thing
<mnemoc>
br-: :)
<Alex1269>
Ok :) At least I have it for myself :) Now time to get normal ir driver....
tinti_ has quit [Remote host closed the connection]
tinti has joined #arm-netbook
tinti has quit [Quit: Leaving]
tinti has joined #arm-netbook
<mnemoc>
Alex1269: btw, there is an old ignored patch on the mailing list implementing a eirq driver which might deserve a 2nd look
<Alex1269>
Any link ? :)
<mnemoc>
search for "[PATCH] Add external interrupt controller for sun4i/sun5i"
<mnemoc>
from dec. 7th
<Alex1269>
Found.
<Alex1269>
It is a very good idea to move eint part from gpio driver to arch init code. But this will lead to a bunch of changes in drivers...
<Alex1269>
mnemoc, why this was ignored ?
<Alex1269>
I moved sys_config init to arch level and this works... I
<Alex1269>
i'll send a patch for this...
aesok has joined #arm-netbook
<Alex1269>
After this we can change CONFIG_GPIO_SUNXI to =y
Avernos_ has joined #arm-netbook
<mnemoc>
Alex1269: I was waiting for your gpiolib driver :)
Avernos has quit [Ping timeout: 248 seconds]
<Alex1269>
and add a simple driver adding a platform device for gpio input buttons :) This will allow to use hotplug subsystem for buttons and contacts
<Alex1269>
I allready have water leak detector connected to cubie and LAMP server on it - I can switch off cold/hot water from work thru internet... :)
anunnaki has quit [Remote host closed the connection]
<focus_it>
http://www.pengpod.com - $110 for 7" Linaro (Ubuntu ARM derivative) Linux with the Linux booting from the flash. It behaves exactly like desktop computer.
<Alex1269>
mnemoc, gpio_request was exported using EXPORT_SYMBOL_GPL(gpio_request); so binary drivers should be gpl to use it...
<sky770>
focus_it: it has issues man
<Alex1269>
They was declared as gpl but lacks source code...
<sky770>
the pengpod (assuming the current shipping 7"/10" tabs) are using Allwinner A10
<theborger>
sky770: no not really
<theborger>
i am looking at the samsung but i just did not want to spend 250
<theborger>
the samsung is a dual core correct? or the exynos5 i should say
<focus_it>
sky778: I agree there are issues for whiny trolls :)
<Gumboot>
theborger: armbrix?
<focus_it>
I mean the device is new and there are bound to be immense technical problems as version 1 ships.
<theborger>
Gumboot: i have a Pi and a GuruPlug. thought about just getting a mototola atrix laptop dock, but really want a laptop based arm :)
<sky770>
focus_it: it is not* about "as only version 1 has shipped" BUT it is about using an SoC which has scattered details/docs/source codes and most of which is incomplete.
<sky770>
Gumboot: <3 armbrix :D
rz2k has joined #arm-netbook
<Gumboot>
I'm tempted, but I don't fancy the shipping costs.
<Gumboot>
More particularly, I don't fancy their choice of courier.
<focus_it>
but still nothing on internal workings of graphics acceleration
<focus_it>
kills a lot of projects and cheats their investors out of chip sales
<sky770>
#ARM
<sky770>
+1
<sky770>
also, I dunno..am somewhat less impressed than vivante 2k's perf. :(
<focus_it>
ARM cheats their investors too - they don't release header files for registers and bit fields. So ANY software ANYONE makes is incompatible with EVERYONE ELSE
<sky770>
a mali-400 MP(4) rocks in comparison :D
<focus_it>
Compare that with Microchip PICs - they sell 1 billion+ chips (slow ones), but all their registers and bit fields have names and even if the underlying hardware changes, one file that maps register names and bit fields repairs it all and makes old software work on new chips
<sky770>
though am looking forward to etnaviv too :|
hg_5 has joined #arm-netbook
<Alex1269>
mnemoc, I just can't figure out how to avoid ifdefs in code to implement this... To export there should be wrapper-function gpio_request with ifdefs
aesok has quit [Remote host closed the connection]
sky770 has quit [Read error: Connection reset by peer]
sky770 has joined #arm-netbook
focus_it has joined #arm-netbook
<techn__>
current stage 3.0 doesnt compile :/
sky770 has quit [Client Quit]
<mnemoc>
techn__: eh??
<techn__>
/linux-sunxi/arch/arm/mach-sun4i/core.c:106:5: error: implicit declaration of function ‘sw_cfg_get_int’ [-Werror=implicit-function-declaration]
<mnemoc>
uhm
<mnemoc>
i might have missed a commit
<mnemoc>
1m
<techn__>
cant find header where that is declared :/
<mnemoc>
it was removed
<mnemoc>
pre-iomapping works in 3.0 by miracle
<mnemoc>
it was removed from 3.4 ages ago
<mnemoc>
but somehow missed that commit when backporting plat-sunxi to 3.0
<Turl>
hno: ping
<Alex1269>
mnemoc, stage/3.4 has same problem yesterday but today problem gone
ln2 has joined #arm-netbook
<mnemoc>
o_O
<ln2>
O_O
<Alex1269>
It is related fb memory reservation
<mnemoc>
i can easy explain the problem in 3.0. but not in 3.4
eFfeM has joined #arm-netbook
<Turl>
make sure you're running 3.4
<mnemoc>
techn__: test now
<Alex1269>
mnemoc, sorry, 3.4 was ok... I had 3.0 compilation problem yesterday
<Alex1269>
mnemoc, I read it - its ok for me... But i'm not sure if leds_default really needed because this can be done using gpio definition at leds_pin_n
Quarx has joined #arm-netbook
<mnemoc>
Alex1269: reply ;-) ... you are the driver author. it's part of the job
<Turl>
xxiao: there were allwinner people on one of those some year(s) ago
vinifm has joined #arm-netbook
<xxiao>
Turl: i saw that. last year it's free, this year it's $800 per attendee
<xxiao>
that may push chinese players away, who only thinks hardware worths money, if anything
<xxiao>
esp for money-tight small players
<xxiao>
i was just old only 5% are from mainland, 95% are from elsewhere
<xxiao>
and there are 300+ attendee already
tinti has quit [Read error: Connection reset by peer]
tinti has joined #arm-netbook
ZaEarl has joined #arm-netbook
ice_ has joined #arm-netbook
<ice_>
Good evening lads.
<ln2>
Hello. =)
<ice_>
What up ln2?
<ln2>
Just hanging out waiting for exciting news. xD
<ice_>
Hehehe
<ice_>
Any idea how to compare reasonably (although that's like comparing oranges with apples) say an ATOM CPU from the 2009-2010 era vs. an ARM Cortex A8 CPU of 2012-2013 in terms of raw CPU calculation power?
<specing>
a8 is the 2010 era
<specing>
the atom will smash it to bits
<ice_>
Alright.
<buZz>
well i am not sure, atom is not so good in FPU
<jelly-home>
ice_: the only reasonable approach is to run the actual workload on both
ZaEarl has quit [Ping timeout: 246 seconds]
<ice_>
I might have found some badass embedded smaller than mini itx propetary sized motherboards that come with an Intel ATOM 330, 1GB of DDR2 onboard, SATA & Gigabit ethernet integrated and can extend the memory to 4GB via standard SO-DIMM DDR2 sticks and all that at least than 49$/36 eur retail.
<roxfan>
atom has better performance but it's much hungrier
<roxfan>
and also needs more circuitry
<ice_>
So that'd smash the f!*@# out of any ARM CPU stuff we can get our hands on at the moment I believe in terms of CPU calculation power, expandability to add RAM easily, low energy consumption and... x86 of course, hello Debian wheezy!
<ice_>
I just have to negociate the price now, chinese are hard with business. :p
<ln2>
There are already Intel SoC's. They will ship at the end of this year. 5 Watts power consumption.
<ice_>
ln2, any URL?
<ln2>
Clover Trail architecture.
<ln2>
AMD also has x86 SoC's that are already shipping with 5 watts power.
<roxfan>
weren't there some phones with intel chips already?
<ln2>
Yes. None in the US.
<mnemoc>
an 30m of battery life?
<mnemoc>
and*
<ln2>
Same as ARM.
<roxfan>
hehe
<ice_>
Oh and apologies in advance for discussing x86 stuff on an... ARM channel. :-)
<ln2>
That's ok. I think really we are interested in low power hardware.
<jelly-home>
2W is quite a lot for something calling itself "off"
<ice_>
That's wake on LAN.
<L84Supper>
ice_: finding quality board stuffers is the difficult part, pricing is actually pretty easy, they expect you to shop around same as they do
<ice_>
Indeed.
<L84Supper>
finding quality anything there is the actual challenge
<ice_>
Welcome to china, welcome to the future!
<L84Supper>
treat it like you would a child that doesn't want to do something and will try every trick to not finish a required task
<L84Supper>
they figure if you don't notice, then it's fine
<L84Supper>
that's pretty much the attitude
<ice_>
You speaking of experience with them?
<L84Supper>
yes
<L84Supper>
children and china
<ice_>
We're borderline racism here, let's keep it civil.
<L84Supper>
not at all
<L84Supper>
it's an over generalization
<ice_>
Or let's just NOT turn it into a "bashing country" contest.
<ice_>
brb anyways
<L84Supper>
not at all, i actually have a business there
ice_ has quit []
ice_ has joined #arm-netbook
<ice_>
L84Supper, so what kind of business do you have?
<L84Supper>
R&D and manufacturing
rz2k has quit [Read error: Connection reset by peer]
<L84Supper>
i don't set policy, I just observe it
<ice_>
L84Supper, mind if I poke you in /msg?
rz2k has joined #arm-netbook
tinti has quit [Quit: Leaving]
Alex1269 has quit [Ping timeout: 245 seconds]
gimli has joined #arm-netbook
penguin42 has joined #arm-netbook
eFfeM has quit [Quit: Leaving.]
ice_ has quit []
Quarx has joined #arm-netbook
cocos has joined #arm-netbook
cocos has quit [Ping timeout: 245 seconds]
MMlosh has quit [Quit: Bye...]
MMlosh_ has joined #arm-netbook
MMlosh_ is now known as MMlosh
<gzamboni>
what does this new gpio driver does in aditional with the ugly gpio old one ?? IRQ external int support ?
<gzamboni>
is there another way of using gpios in c programming besides of using the sys/ ... filesystem ?
SouL_ has joined #arm-netbook
SouL_ has left #arm-netbook [#arm-netbook]
<RaYmAn>
the gpio stuff is usually used by other drivers
lerc has quit [Ping timeout: 245 seconds]
Skrzyp has left #arm-netbook ["WeeChat 0.4.0"]
<specing>
gzamboni: mmaping() /dev/ram and accessing the GPIO module directly
<mnemoc>
it might be a good idea to make a lib out of sunxi-tools' pio.c
<mnemoc>
with the obvius problem of requiring uid 0
<specing>
CAP_GPIO ? :D
<specing>
it probably doesen't exist
<specing>
But there sure is some capability that flows with the purpose
<mnemoc>
specing: it's the access to /dev/mem that is obviusly restricted
<specing>
Oh so we are not talking about the /sys stuff, are we?
<mnemoc>
he wanted to avoid accessing each pin as fd
<gzamboni>
i did with an olimex board using imx233, i did accessed direclty including a gpio-mmap.h
<gzamboni>
for the test i made it is much faster than accessing the files from the sys dir
<mnemoc>
sunxi-tools's pio.c knows to work with the pio register from userspace
<mnemoc>
it can be refactored into a library
<mnemoc>
but anyhow, /dev/mem access (to mmap) requires root
<techn__>
mnemoc: please apply that divide-0 patch.. its showstopper currently :)
<mnemoc>
drachensun's inline diff?
<gzamboni>
i havent saw yet this pio.c from the sunxi tools, let me check
<techn__>
hans's patch is beter imho
<mnemoc>
ah, sorry. didn't see it coming
<gzamboni>
i saw the presentation of libv at fosdem. grate work you are all doing
anunnaki has joined #arm-netbook
<gzamboni>
And connor aparently is a genius. When i had his age i was learning html code :P
<techn__>
gzamboni: I programmed my first lines 20 years ago :p
lerc has joined #arm-netbook
<techn__>
but that was about 10 lines of turbo bascal.. nothing like connor :D
* mnemoc
wonders if gpiolib provides an standard mmap/ioctrl interface to the whole banks
<mnemoc>
not the same as raw access to the registers, but should be a good middle point
<gzamboni>
i am learning a lot here and in the ml and looking at the patches, for the moment im in spector mode
<gzamboni>
i did program already in c and asm, but it wasnt like in the kernel with buffers and all those file relationships
<mnemoc>
techn__: divide by zero is stage-only or on the main branches too?
<techn__>
I reproduced that problem only with current stage
<techn__>
so stage only :/
<mnemoc>
pushed
<techn__>
but it wouldn't hurt non-stage if it applies
<libv>
seems like Xlib has been broken over the last 2 decades, or at least, it has been badly wrapped by the wm
<ssvb>
libv: I think it was hramrach
<libv>
ah, ok
<libv>
in any case, that howto i pointed to, as well as any hello world with xlib, has this error
<libv>
apart from that, it really was just a bit of busywork to use xlib and egl
<ssvb>
libv: IIRC es2_info failed on exit, valgrind reported some sort of "use after free" problem
L84Supper has joined #arm-netbook
<libv>
heh, a fresh run of es2_info just hangs with me now :)
<libv>
X is broken
<libv>
sadly, the same mindset that broke X is at work creating the follow-up, and reinventing everything along the way
<ssvb>
or in this case the mali blob :)
<libv>
i think it used to return nicely before
<libv>
or at least returned
<ssvb>
but we can't really debug it properly :-/
<libv>
heh, it does get a DestroyNotify
<libv>
(says xtrace)
* libv
kills the xserver and tries again
<libv>
ssvb: i rather believe atm that this is not a mali-libs issue
<ssvb>
libv: after looking at xf86-video-mali code, I'm not so sure. I guess it could be so that the X11/DRI2 integration was done by some junior developers, and the X11 code might be just as ugly on the blob side...
<libv>
ssvb: xtrace tells me that es2_info gets a DestroyNotify
<libv>
ssvb: yet es2_info does not quit.
<ssvb>
libv: es2_info is linking libMali.so, and it has some X11 related code for EGL residing in this blob (at least for requesting DRI2 buffers), this code could be screwing up something
<ssvb>
libv: but that's just a guess
abesis has joined #arm-netbook
<libv>
i have been near the X.org community for long enough to know that the binary is not always the issue.
eebrah has quit [Read error: Connection reset by peer]
<ssvb>
libv: if you can find the root cause for this problem, that would be really great :-)
user135 has quit [Quit: Leaving]
alcides has joined #arm-netbook
alcides has joined #arm-netbook
MMlosh has quit [Ping timeout: 245 seconds]
MMlosh has joined #arm-netbook
<ssvb>
libv: as a somewhat unrelated thing, I have taken care to eliminate OpenGL (libGL.so) on my old x86 laptop a few days ago, this should make it a bit easier to do GLESv2 compatibility testing
<hramrach>
but can't get the mesa demos eglut from which I got the X11 code to work with Mali fb libraries
<hramrach>
the es2_info program is particularly broken. Unlike other X programs it manages to corrupt its memory
<hramrach>
you get glibc error if you run it a few times
<hramrach>
ssvb:
XenGi is now known as XenGi_
marcus__ has joined #arm-netbook
<techn__>
something is really broken if process leaves garbage behind
<techn__>
memory leak in kernel?
<ssvb>
techn__: valgrind tells me that it is the use of "memory buffer after free" problem
<techn__>
yeah.. but that should be inside that process?
<ssvb>
techn__: no need to leave garbage behind if you can do it wrong on every run :)
<techn__>
and process dies after that
<techn__>
but if it effects to next run.. problem should be in kernel
<ssvb>
not really
<ssvb>
you just get unpredictable results on every run
MarcusSt has quit [Ping timeout: 244 seconds]
<techn__>
also X or other server process could be reason
<hramrach>
well, no. the program manges its memory
<ssvb>
yes, maybe
<ssvb>
I mean anything in the system might have indirect influence on the bugs with unstable reproducibility
<techn__>
hramrach: yes but kernel should cleanup open handles when that process dies
<hramrach>
does it not?
<ssvb>
the es2_info program is a bit special because it does not try to render anything
<ssvb>
could it be that the mali code gets confused by this (by relying on some sort of lazy initialization of some structures on certain API calls which are missing in es2_info)?
<ssvb>
hramrach: is there anything else that is failing for you (other than gnome-shell)?
FergusL has joined #arm-netbook
<ssvb>
hramrach: also what exactly is wrong with eglut demos?
alcides has quit [Quit: To be continue...]
Makawity has joined #arm-netbook
<Makawity>
hi there
<hramrach>
ssvb: they run fine in X11 but use some Mesa specific extensions when not under X11
<hramrach>
and gnome-shell is working as poorly as ever, no problem with that
<hramrach>
thanks for bringing back the windows :)
Makawity has left #arm-netbook [#arm-netbook]
<ssvb>
hramrach: I still need to bring back the ARGB cursor (in the case when layers are used) :)
<ssvb>
hramrach: have you tried any other compositing managers? kwin_gles seems to work reasonably good
revident has joined #arm-netbook
discopig has joined #arm-netbook
<hramrach>
ssvb: not yet
<hramrach>
running out of space on the card
<libv>
i think i would have to conclude that our egl is indeed broken
<libv>
mali_egl_cleanup_internal is a destructor called when libc is tearing down
simosx has quit [Quit: Αποχώρησε]
<libv>
it is even being run after the xdisplay has been closed
<ln2>
Does anyone know the maximum resolution of the A10's 24 pin TTL output?
<libv>
and to clean up some of its own surfaces, it tries to initialize the DRI2 extension
<libv>
on a closed display...
<libv>
maybe by hexediting a nop into __LINUXeglDestructor, we can circumvent this
<ssvb>
libv: if it only affects es2_info, then it might be not so important?
<libv>
i believe that it affects every program that tries to clean up X on exit
<ssvb>
libv: don't "normal" applications trigger the initialization of DRI2 way before the teardown?
<libv>
ssvb: the issue is that we try to re-initialize after the display has been torn down already
<ssvb>
in every case or only reproducible with es2_info?
revident has quit [Quit: SANITY.... we'll get back to you on that. -- The Universe]
<libv>
i am getting the same in my hacked test program
<libv>
and hramrach is getting this issue too
<ssvb>
ok, confirmed, I can also reproduce this with a simple program
<libv>
bx lr fixes it apparently
<ssvb>
we may want to check if the offending code might be in fact in libdri2
<libv>
mnemoc: i have just succesfully hacked r3p0-hf-x11 to not deadlock or crash upon exit, when the xdisplay has been closed already
<libv>
ssvb: imho there should be any attempt to clean up anything
<libv>
should not even
<libv>
the kernel should clean up on its own, X and the DRI2 extension should clean up when the client vanishes
<libv>
the fact that we try to clean up things which have vanished already, as our client application did so for us, is exactly what runs us into trouble
<libv>
so i think it is perfectly legal to not do anything specific on exit()