On Friday 20 April 2007 19:04, you wrote:
> > I have seen your code in xserver which does the same job for downscaling,
> > but in nonoptimized C and with much higher impact on quality. Using JIT
> > scaler there can improve both image quality and performance a lot. The
> > only my concern is about instruction cache coherency. As ARM requires
> > explicit instructions cache flush for self modyfying or dynamically
> > generated code, I wonder if using just mmap is safe (does it flush cache
> > for allocated region of memory?). Maybe maemo kernel hackers/developers
> > can help with this information?
>
> arm linux support flush icache by syscall "cacheflush",
>
> qemu have this function:
> static inline void flush_icache_range(unsigned long start, unsigned long
> stop)
> {
> register unsigned long _beg __asm ("a1") = start;
> register unsigned long _end __asm ("a2") = stop;
> register unsigned long _flg __asm ("a3") = 0;
> __asm __volatile__ ("swi 0x9f0002" : : "r" (_beg), "r" (_end), "r"
> (_flg));
> }
>
> you can reference kernel source arch/arm/kernel/traps.c and
> include/asm-arm/unistd.h
Thanks, it works. But I'm worried about [1]. Looks like EABI has a new syscall
interface and this code from qemu uses old ABI. And from reading description
at the wiki page, compatibility with old ABI can be disabled (and it makes
sense disabling it as this compatibility reduces performance a bit).
I wonder if there is a better portable solution (running on any ARM linux or
even better on any POSIX compatible system). It would be reasonable to
assume that allocating memory with mmap implies that we are going to
execute code from that area and instructions cache should be flushed for it:
mmap(0, some_buffer_size, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
But I wonder if mmap requesting executable block of memory really does
instructions cache flush in reality?
I just want to submit this ARM optimized scaler to upstream ffmpeg and want to
make it as portable as possible.
1.
http://wiki.debian.org/ArmEabiPort#head-96054c6cb4209b4a589e645dd50ac0fe133b8ced
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
