Turns out maemo's old gcc 4.2.1 doesn't include any arch
optimized swapXX() functions, just plain C implementations.
Before we pull in lots of linux kernel headers for the
C implementation, just stick to rockbox's own version.
Change-Id: Ic28b41b52fe47f814c7f3897ce15334a42b6c5e2
This one is much more efficient than using a generic table widget.
Change-Id: I3578964eead746e656f6b0a8dcec0f8442deb13d
Reviewed-on: http://gerrit.rockbox.org/1022
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
With the previous code, tab names would be ignored if tab is detached
which can happen early on.
Change-Id: I9eac4202850f3e79a04590a4ba1444850ec6a583
Reviewed-on: http://gerrit.rockbox.org/986
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Optimizes YUV to RGB conversion using ARMv5 multiply-accumulate
intructions for operations and data tables for saturation.
This first patch set includes the three versions i have developed.
Although iPod Classic need to use the latest version to reach 30fps,
old versions may serve other targets.
All versions are based on current SVN algorithm (round->scale->add)
using the same coefficients, so output results are identical.
Version history:
ARMv4:
- use all available registers to calculate four pixels within each
loop iteration.
- avoid LDR interlocks.
ARMv5TE:
- use ARMv5TE+ 1-cycle multiply-accumulate instructions.
ARMv5TE_WST:
- use data tables (256 bytes) for RBG565 saturation.
Benchmarks results using iPod Classic (ARM926EJ 216Mhz):
size test_fps (1) mpegplayer (2)
bytes YUV YUV1/4 average min/max
----- ----------- ------------------
SVN-20141107 528 27.8 110.0 11035 10864/13397
ARMv4 480 28.8 114.0 9767 9586/12126
ARMv5TE 468 29.7 117.5 8751 8584/11118
ARMv5TE_WST 544 33.6 133.0 6355 6316/6403
(1) boosted
(2) play full elephants_dream_320x240.mpg file (15693 frames) using
mpegplayer, patched RB measures YUV to RGB565 frame conversion
time (microseconds)
Compared against the WST version, the ARMV5TE version w/o cached
saturation tables is slower, but it is smaller and i have doubts
about the power consumption.
Change-Id: I2b6a81804636658d85a1bb104ccb2055e77ac120
Reviewed-on: http://gerrit.rockbox.org/1034
Reviewed-by: Cástor Muñoz <cmvidal@gmail.com>
Tested: Cástor Muñoz <cmvidal@gmail.com>
7d1a47cf13 introduced a regression that broke it completely so that
it couldn't boot into the main menu anymore. It had a faulty call to
get_volume_name() which made handle_special_links() act up. This broke
every open() and opendir() (and friends) library calls.
Change-Id: I399960ca8fb6e3bcc1f25c9b4a3c19a6d28b77bd
Commit 7d1a47cf ("Rewrite filesystem code (WIP)") exposed
bug in rk27xx sd driver. Buffer passed to sd_read/write_sectors()
doesn't has to be cacheline aligned. DMA transfers on
unaligned buffers is quiet dangerous thing.
Make sure that the buffer is aligned to cacheline size,
If not use a temporary aligned buffer for DMA transfer.
Change-Id: I91420f2b8d58159c80c3f15f4b35e88ea0dfd14c
This file revealed several problems with our ASF parser:
1) The packet count in the ASF was actually a 64 bit value,
leading to overflow in very long files.
2) Seeking blindly trusted the bitrate listed in the ASF header
rather than computing it from the packet size and number of packets.
Fix these problems and fix a few minor issues.
Change-Id: Ie0f68734e6423e837757528ddb155f3bdcc979f3
The current code assumed that READ/WRITE would produce atomic read/writes for
8/16/32-bit words, which in turned put assumption on the memcpy function.
Since some memcpy implementation do not always guarantee such strong assumption,
introduce two new operation READ/WRITE_ATOMIC which provide the necessary
tools to do correct read and write to register in a single memory access.
Change-Id: I37451bd5057bb0dcaf5a800d8aef8791c792a090
Use 32 bytes for cache line length (arm926ej-s), this prevents
misalignments of ATA storage buffer which in some builds could
cause weird faults.
Change-Id: I88dc595d251315620ec49b0251ddc039ff47181e
Reviewed-on: http://gerrit.rockbox.org/1031
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
