Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
DocScrutinizer05 is now known as jOERG_rw
jOERG_rw is now known as jOERG_zzZZzz
jOERG_zzZZzz is now known as jOERG_42
jOERG_42 is now known as DocMobilizer
GNUtoo-desktop has quit [Quit: [INFO] fsogsmd : received signal -11, exiting.]
<larsc>
viric: nice trick reusing the existing handlers :)
<viric>
it took me a while to figure all out :)
<viric>
now I've a *segfault* in webkit.
<viric>
hm there is a null pointer when there should not be.
<viric>
who knows.
<viric>
at least webkit runs further.
Ayla has joined #qi-hardware
compcube has joined #qi-hardware
Freemor has joined #qi-hardware
Freemor has left #qi-hardware [#qi-hardware]
antgreen has joined #qi-hardware
<lindi->
I have been using chromium on openmoko for quite some time already
methril has joined #qi-hardware
xwalk_ has quit [Ping timeout: 246 seconds]
xwalk_ has joined #qi-hardware
xwalk_ has quit [Ping timeout: 240 seconds]
pabs3 has joined #qi-hardware
DocScrutinizer has quit [Disconnected by services]
DocScrutinizer has joined #qi-hardware
DocScrutinizer06 has joined #qi-hardware
DocScrutinizer05 has quit [Ping timeout: 244 seconds]
xwalk_ has joined #qi-hardware
<viric>
lindi-: is that mips?
<lindi->
no, armel
<lindi->
but you probably have same bugs with unaligned accesses
GNUtoo-desktop has joined #qi-hardware
<viric>
well, I was using webkit 1.4.0. Maybe a newer webkit works better. And the troubles were in the unaligned-access-emulation of mips.
<viric>
specifically.
<viric>
lindi-: and it's related to FPU, that the openmoko maybe does not have
<lindi->
ok
compcube has quit [Remote host closed the connection]
compcube has joined #qi-hardware
compcube has quit [Changing host]
compcube has joined #qi-hardware
jekhor has quit [Ping timeout: 248 seconds]
<mth>
unaligned access emulation is a horrible thing anyway; it's much better to fix the program doing the access
<viric>
of course
<viric>
but it becomes a matter of performance, then. Not a matter of "the program does not run"
<viric>
and with an 'echo' to a debugfs file, you can make all programs sigbus, if you want, on unaligned access. It becomes up to the kernel user.
xwalk_ has quit [Ping timeout: 245 seconds]
compcube has quit [Quit: Leaving]
<mth>
yeah, but I think that trying to make broken programs run is not a good idea, because it decreases the chance of them getting fixed
<mth>
also, the resulting system is more complex, like you found out when there was a bug in the unaligned access emulation
<viric>
then maybe you'd like the sigbus behaviour to be the default, and the emulation not default
<viric>
but it should not be about not having that code in the kernel at all
<viric>
Imagine a super-complex package has unaligned accesses, and the producers of the package do not give a penny for your platform.
<viric>
(hypothetical case :)
<mth>
the emulation can be useful even if only for logging where in the program the unaligned accesses come from
<mth>
but indeed I wouldn't want it enabled by default
<mth>
same for floating point emulation: I'd rather have the program crash so that I know that softfloat support failed
xwalk_ has joined #qi-hardware
DocScrutinizer06 is now known as DocScrutinizer05
xiangfu has quit [Ping timeout: 246 seconds]
ChanServ has quit [shutting down]
ChanServ has joined #qi-hardware
mth is now known as mth_
mth_ is now known as mth
qwebirc24230 has joined #qi-hardware
qwebirc24230 has quit [Client Quit]
compcube has joined #qi-hardware
compcube has quit [Changing host]
compcube has joined #qi-hardware
FrankBlues has joined #qi-hardware
* DocScrutinizer05
idly wonders why /ns help in this chan and now is the old version still, while /ns help in another chan and 2h ago showed some new details >>
<DocScrutinizer05>
[16.06.2012 16:43:29] [Notice] -NickServ- If a registered nick is not used by the owner for 150 days,
<DocScrutinizer05>
[16.06.2012 16:43:29] [Notice] -NickServ- NickServ will drop the nickname, allowing it to be reregistered.
<DocScrutinizer05>
1h ago
<viric>
I'm trying fpu code in that loongson2f... and all I compiled looks broken :)
<viric>
lame has lots of nans (have to be emulated)
<viric>
ffmpeg encoding with libvorbis looks quite mad too; I don't know if due to decoding an mp3, or encoding the ogg.
<viric>
I wonder what other floating point code I could run to test
xwalk_ has quit [Ping timeout: 246 seconds]
xwalk has quit [Ping timeout: 246 seconds]
xwalk has joined #qi-hardware
xwalk_ has joined #qi-hardware
antgreen has quit [Ping timeout: 265 seconds]
wej has quit [Ping timeout: 248 seconds]
<qi-bot>
[commit] Paul Cercueil: ASoC: JZ4740: delay activation of the DAC to work around a sound bug. (jz-3.4) http://qi-hw.com/p/qi-kernel/ef84c71
wej has joined #qi-hardware
<larsc>
Ayla: that's an interresting way to implement a msleep() ;)
<Ayla>
isn't it? :)
<Ayla>
I actually wasn't aware of msleep()...
<Ayla>
I know mdelay, not msleep
<larsc>
msleep sort of does what you just implemented
<Ayla>
mth: that means we could replace all mdelay() by msleep() on the SLCD panels code
<Ayla>
so that the other threads can continue when the panel is initializing
<Ayla>
that was a request reported on the kernel bug tracker
<mth>
yes, sounds like a good idea
<Ayla>
at which point is it better to use msleep over mdelay, or the other way around?
<Ayla>
on some parts of the code, I waits only 10ms
<Ayla>
s/I/it
<qi-bot>
Ayla meant: "on some parts of the code, it waits only 10ms"
<Ayla>
msleep() probably introduces a higher delay
<wpwrak>
"only" 10 ms :-)
<Ayla>
but I'm not sure it's important whether it waits longer than 10ms or not
<wpwrak>
that's a pretty nasty delay, if you spend that time spinning
<Ayla>
well, the panel enable function spins for like one second total
<Ayla>
510ms for the ili9325 panel
<wpwrak>
mdelay ? urgh
<Ayla>
yes :)
<Ayla>
IIRC we use HZ=250 on dingoo, so a msleep() will last 4ms minimum
<Ayla>
and msleep(10) will sleep 12 milliseconds
<wpwrak>
just hope you don't have anything remotely real-time-ish on that machine :)
<Ayla>
we do, sort of
<Ayla>
the sound output
<larsc>
which is taken care of by dma
<mth>
only for the span of the current period though
<mth>
the sound output is broken when the SLCD init happens
<mth>
when unblanking, for example
<mth>
Ayla: I think that even 1 ms is a lot of time for this CPU
<Ayla>
larsc: yes, but the app that produces sound is blocked
<mth>
and afaik the 4 ms time slices matter when there are multiple active threads, but it doesn't mean a single active thread has to wait for the next time slice
<Ayla>
ok
<Ayla>
I replaced all mdelays by msleeps, and it works good
<Ayla>
now the sound doesn't stop when I un-blank the screen on GMU