This is a rewrite of the clocking section, the resulting system
frequencies are the same as the current git version.
This pàtch uses fixed FClk and just one register is written to switch
all system frequencies, it needs less steps than the current git
version to reach the desired frequency, so it is faster and safer.
Includes functions to step-up/down over a table of predefined set of
frequencies.
The major difference is that Vcore is decreased from 1050 to 1000 mV.
See clocking-s5l8702.h for more information.
Change-Id: I58ac6634e1996adbe1c0c0918a7ce94ad1917d8e
The main "innovation" in this patch are two "virtual buttons"
for the record switch on YH92x targets. When the switch state
changes, a single BUTTON_REC_SW_ON or .._OFF button event will
be generated. Thus keymap code can react on switching, but
not on the actual state of the switch.
Wherever sensible, the following user scheme is applied:
- use PLAY as confirm button
- use REW button or Long REW to exit
- use REC (YH820) or FFWD (YH92X) as modifier key for button combos
Change-Id: Ic8d1db9cc6869daed8dda98990dfdf7f6fd5d5a1
Adds ata_read_smart() function to storage ATA driver, current
SMART data can be displayed and optionally written to hard
disk using System->Debug menu.
Change-Id: Ie8817bb311d5d956df2f0fbfaf554e2d53e89a93
This patch limits the drawn USB current to 100/500mA, instead of
the actual 200/1000mA settings. It also initializes other USB power
related GPIOs.
Solves some USB disconnect issues: FS#12990, FS#12956. I am using a
powered USB HUB with no problems (Vusb=5.05V unloaded), but there
are lots of USB disconnects when using the motherboard USB ports
(Vusb=4.91V), this patch solves all my issues.
Actually, it seems that the USB current drain is limited to 1000mA,
when a load peak occurs most USB2 ports deliver more than 500mA, as
current consumption increases the USB voltage decreases, an excesive
voltage drop produces USB disconnections. Limiting USB current drain
to 500mA also limits the voltage drop, preventing subsequent USB
failures.
Anyway, to minimize voltage drop, it is recommended to use quality
cables and preferably connect to USB ports with higher Vusb.
Change-Id: I1b931aa18ec93bfd1214e475a72e42893eff52f6
- polling/IRQ modes for Tx/Rx (TODO?: DMA)
- fine adjust for Tx/Rx bitrates
- auto bauding using HW circuitry
- status and stats in debug screen
Change-Id: I8650957063bc6d274d92eba2779d93ae73453fb6
This patch has been tested on iPod 80 and 160slim, actually
it works but some updates must be done to the final version:
- unlimitted input buffer
- decrease CHUNK_SIZE
- use non-cached addresses instead of discard d-cache ???
Capture hardware versions:
Ver iPod models capture support
--- ----------- ---------------
0 80/160fat dock line-in
1 120/160slim dock line-in + jack mic
HW version 1 includes an amplifier for the jack plug mic.
Capture HW detection only tested on iPod 80 and 160slim.
CODEC power:
AFAIK, OF powers CS42L55 at VA=2.4V for capture (1.8V for
playback) and turns on the ADC charge pump. CODEC datasheet
recommmends to disable the charge pump for VA>2.1V.
CS42L55 DS, s4.13 (Required Initialization Settings): for
VA>2.1V, some adjustments "must" be done using undocummented
"control port compensation" registers. OF does not modifies
these registers when VA=2.4V.
This patch configures capture HW in the same way as OF does.
TODO:
- ADC full scale voltage depends on VA, perform tests to find
clipping levels for VA=1.8V and VA=2.4V
Change-Id: I7e20fd3ecaa83b1c58d5c746f5153fe5c3891d75
This patch uses the new pl080 DMA driver for I2S playback and LCD
update. I have tried to be as fiel as possible to the current
behaviour, algorithms and configurations are the same, but using
the new driver. Other modifications:
Playback:
- CHUNK_SIZE is decreased from 42988 to 8188 bytes, it does not
affect normal playback (block size 1024), was tested using
metronome (block size 46080). This change is needed because the
new code commits d-cache range instead of commiting the whole
d-cache, maximum time spent commiting the range should be
limited, CHUNK_SIZE can be decreased even more if necessary.
- pcm_play_dma_start() calls pcm_play_dma_stop() to stop the
channel when it is running (metronome replays the tick sound
without stopping the channel).
- pcm_play_dma_get_peak_buffer(): same as actual SVN function but
returns samples count instead of bytes count.
TODO: AFAIK, actually this function is not used in RB. Not tested,
but probably this function will fail because it returns pointers
to the internal double buffer.
LCD update:
- suppresses lcd_wakeup semaphore and uses yield()
Change-Id: I79b8aa47a941e0dd91847150618f3f7f676c26ef
Motivation:
This driver began as a set of functions to help to test and
experiment with different DMA configurations. It is cumbersome,
time consuming, and leads to mistakes to handle LLIs and DMA
registers dispersed along the code.
Later, i decided to adapt an old DMA queue driver written in the
past for a similar (scatter-gather) controller, all task/queue
code is based on the old driver.
Finally, some cleaning and dmac_ch_get_info() function was added
to complete RB needs.
Description:
- Generic, can be used by other targets including the same
controller. Not difficult to adapt for other similar
controllers if necesary.
- Easy to experiment and compare results using different
setups and/or queue algorithms:
Multi-controller and fully configurable from an unique place.
All task and LLI management is done by the driver, user only
has to (statically) allocate them.
- Two queue modes:
QUEUE_NORMAL: each task in the queue is launched using a new
DMA transfer once previous task is finished.
QUEUE_LINK: when a task is queued, it is linked with the last
queued task, creating a single continuous DMA transfer. New
tasks must be queued while the channel is running, otherwise
the continuous DMA transfer will be broken.
On Classic, QUEUE_LINK mode is needed for I2S continuous
transfers, QUEUE_NORMAL is used for LCD and could be useful
in the future for I2C or UART (non-blocking serial debug) if
necessary.
- Robust DMA transfer progress info (peak meter), needs final
testing, see below.
Technical details about DMA progress:
There are comments in the code related to the method actually
used (sequence method), it reads progress without halting the
DMA transfer. Althought the datasheet does not recommend to do
that, the sequence method seems to be robust, I ran tests calling
dmac_ch_get_info() millions of times and the results were always
as expected (tests done at 2:1 CPU/AHB clock ratio, no other
ratios were tried but probably sequence method will work for any
typical ratio).
This controller allows to halt the transfer and drain the DMAC
FIFO, DMA requests are ignored when the DMA channel is halted.
This method is not suitable for playback because FIFO is never
drained to I2S peripheral (who raises the DMA requests). This
method probably works for capture, the FIFO is drained to memory
before halting.
Another way is to disable (stop) the playback channel. When the
channel is disabled, all FIFO data is lost. It is unknown how much
the FIFO was filled when it was cleared, SRCADDR counter includes
the lost data, therefore the only useful information is LINK and
COUNT, that is the same information disponible when using the
sequence method. At this point we must procced in the same way as
in sequence method, in addition the playback channel should be
relaunched (configure + start) after calculating real SRCADDR.
The stop+relaunch method should work, it is a bit complicated,
and not valid for all peripheral FIFO configurations (depending
on stream rate). Moreover, due to the way the COUNT register is
implemented in HW, I suspect that this method will fail when
source and destination bus widths doesn't match. And more
important, it is not easy to garantize that no sample is lost
here or there, using the sequence method we can always be sure
that playback is ok.
Change-Id: Ib12a1e2992e2b6da4fc68431128c793a21b4b540
This patch implements a simple API to use the external interrupt
hardware present on s5l8702 (GPIO interrupt controller). This
GPIOIC has been fully tested using emcore apps.
Code is based on openiBoot project, there are a few modifications
to optimize space considering we will only use two or three external
interrupts. The API compiles and works, but has been never used,
therefore probably will need some changes to the final version.
External interrupts are necessary for jack remote+mic controller
(see iAP Interface Specifiction: Headphone Remote and Mic System),
this controller is located at I2C bus address 0x72, there is a IRQ
line for remote button press/release events routed to GPIO E6. At
this moment, the functionallity of this controller has been
extensively tested using emcore, getting a lot of information about
how it works. Microphone is already working on RB, jack accessory
detection and button events are work in progress.
PMU IRQ line is also routed to GPIO F3, it signals many events:
holdswitch, usb plug, wall adapter, low battery... The use of PMU
interrupts is the orthodox way of doing things, at this moment
there is no work done in this direction, there are a lot of PMU
events and i think it is a matter of discursion what to do and how.
Change-Id: Icc2e48965e664ca56c9518d84a81c9d9fdd31736
It was possible for interrupts of higher priority than the current IRQ
level to attempt to restart the interface while it was still active on
a transfer. The list modification also wasn't protected within the I2C
ISR itself.
Change-Id: I70635c307a1443bba6801c588cf1efde299db9a4
This patch enables "Settings -> Sound Settings -> DAC's filter roll-off" for the
iBasso DX50.
Confirmed working on iBasso DX50, firmware 1.6.
Change-Id: I901615541d8fa4f6550c5156cf8c6069f5bdf9d0
Depends on http://gerrit.rockbox.org/r/#/c/1043/.
This patch adds a new setting in Settings -> General -> System: USB Mode.
Usable in Quickscreen and Shortcuts.
Possible settings are:
- Mass Storage: The default, on USB connect export the internal and external
drives as usual. Rockbox will exit gracefully in this case, since the internal
drive (/mnt/sdcard) is exported as mass storage device and Android prevents
Rockbox from continued execution.
- Charge Only: USB charge only, do not export the internal and external drives.
This will not close Rockbox.
- ADB: Enable the Android Debug Bridge. This will not close Rockbox.
Charge only and ADB are actually the same, since it is not yet established if
charge only is doable without adb and major hooks into Android.
German translation provided.
This may be genric for Android based devices but is only enabled
for iBasso Devices. Other maintainers may choose do adopt this.
Change-Id: I616247c29946c6595ebcf8f0c14b2410c9f0498b
Depends on http://gerrit.rockbox.org/r/#/c/1043/.
This patch adds a new setting in Settings -> General
-> System: Freq Scaling Governor
Usable in Quickscreen and Shortcuts.
Possible settings are:
- Conservative: Slow frequency switching.
- Ondemand or Interactive: Fast frequency switching.
- Powersave: Allways lowest frequency.
- Performance: Allways highest frequency.
German translation provided.
This may be genric for Android kernel based devices but is only enabled
for iBasso Devices. Other maintainers may choose do adopt this.
Change-Id: I10296f5be9586ad3a409105db0cd03682a30e9c1
Reorganization
- Separated iBasso devices from PLATFORM_ANDROID. These are now standlone
hosted targets. Most device specific code is in the
firmware/target/hosted/ibasso directory.
- No dependency on Android SDK, only the Android NDK is needed.
32 bit Android NDK and Android API Level 16.
- Separate implementation for each device where feasible.
Code cleanup
- Rewrite of existing code, from simple reformat to complete reimplementation.
- New backlight interface, seperating backlight from touchscreen.
- Rewrite of device button handler, removing unneeded code and fixing memory
leaks.
- New Debug messages interface logging to Android adb logcat (DEBUGF, panicf,
logf).
- Rewrite of lcd device handler, removing unneeded code and fixing memory leaks.
- Rewrite of audiohw device handler/pcm interface, removing unneeded code and
fixing memory leaks, enabling 44.1/48kHz pthreaded playback.
- Rewrite of power and powermng, proper shutdown, using batterylog results
(see http://gerrit.rockbox.org/r/#/c/1047/).
- Rewrite of configure (Android NDK) and device specific config.
- Rewrite of the Android NDK specific Makefile.
Misc
- All plugins/games/demos activated.
- Update tinyalsa to latest from https://github.com/tinyalsa/tinyalsa.
Includes
- http://gerrit.rockbox.org/r/#/c/993/
- http://gerrit.rockbox.org/r/#/c/1010/
- http://gerrit.rockbox.org/r/#/c/1035/
Does not include http://gerrit.rockbox.org/r/#/c/1007/ due to new backlight
interface and new option for hold switch, touchscreen, physical button
interaction.
Rockbox needs the iBasso DX50/DX90 loader for startup, see
http://gerrit.rockbox.org/r/#/c/1099/
The loader expects Rockbox to be installed in /mnt/sdcard/.rockbox/. If
/mnt/sdcard/ is accessed as USB mass storage device, Rockbox will exit
gracefully and the loader will restart Rockbox on USB disconnect.
Tested on iBasso DX50.
Compiled (not tested) for iBasso DX90.
Compiled (not tested) for PLATFORM_ANDROID.
Change-Id: I5f5e22e68f5b4cf29c28e2b40b2c265f2beb7ab7
System -> Debug (Keep Out) -> View CPU stats
Will now show the current cpufreq scaling governor, minimum, current and
maximum cpufreq scaling frequency for each CPU.
This may be genric for Android kernel based devices but is only enabled
for iBasso Devices. Other maintainers may choose do adopt this.
Change-Id: I53e212f8707bf2abaa557e297293fb559ac37058
The GPIO APIs for ypr0 and ypr1 targets was messy, requiring a
direct communication via several ioctls calls.
Since it is planned to add support to other devices, more GPIO are
going to be used. For that reason the functions shall be clear and
easy to use.
Change-Id: Ia2304335e1fed1305cc2c4320bd4c097e13079be
Some people reported strange charging times and
strange battery life.
Charging by OF: 25 hours; RB: 18 hours
It has been found that there are at least two issues here:
1) the way of getting battery charging status wasn't
really accurate. This attempts to fix that issue.
This patch also simplifies some code (opening a
device is no more needed, for example).
To technically explain, battery charging implies first a constant
current mode (where the voltage increases) and then a constant
voltage mode (where, obviously, the voltage reads more or less
the same). The old way the End Of Charge was detected was based solely
on the voltage, while now it is based on chip's EOC interrupt,
which should be more accurate.
2) OF explicitly sets a constant current 350 mA, while we usually had
55 mA (by as3543 default).
This wasn't discovered before since there is a caching problem
("an accurate guess") in the Samsung power mgmt Linux module,
thus its debugging dumper wasn't really working, reporting a 55 mA current.
Strangely this option should have been set by the bootloader
but apparently it does not.
Some testing is still needed, but I confirm that with this patch
I could run a benchmark for 25 hours (vs. 18 hours), by charging
within Rockbox of course.
Change-Id: I3bd921e86b9018d1cc3c720d15cc46896e8490b3
Except for unfinished or experimental ports, it isthe case that
USE_ROCKBOX_USB and HAVE_USBSTACK are both defined or both undefined.
Furthermore, it is a leftover of some early developments on the USB stack and
doesn't make sense anymore.
Change-Id: Ic87a865b6bb4c7c9a8d45d1f0bb0f2fb536b8cad
Reviewed-on: http://gerrit.rockbox.org/1091
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
The backlight driver always writes a bogus value
from memory into the LCD brightness register.
Fix it up by adding bounds checks and
use a more sane default value.
While looking at the code, I noticed
that BACKLIGHT_CONTROL_SET probably ignores
the desired brightness level, too.
Note: Please test on real hardware, I don't own it.
cppcheck reported:
[rockbox/firmware/target/arm/s3c2440/mini2440/backlight-mini2440.c:53]: (error) Array 'log_brightness[13]' accessed at index 255, which is out of bounds.
Change-Id: Iaafa929a8adaa97b93ebcb66e1f6bd3bf0dad84e
While the right GPIO location is accessed,
the result of the logical AND was tested wrong.
I don't have this hardware, but I can imagine
that bug caused ide_power_enable() to be called
more times than it needed to be.
cppcheck reported:
[rockbox/firmware/target/arm/pbell/vibe500/power-vibe500.c:101]: (style) Expression '(X & 0x8) == 0x1' is always false.
Change-Id: I98498f79d383c6f29869e170bfc94ba9a0d2ba7e
The refactoring of the audio thread in this commit
-----------------------------------------------
commit 5857c44017
Author: Michael Sevakis <jethead71@rockbox.org>
Date: Fri May 31 02:41:02 2013 -0400
Refactor audio thread to run both recording and playback.
-----------------------------------------------
moved pcm_init() next to dsp_init() in apps/main.c:init().
Before that pcm_init() was called by audio_init().
Unfortunately the maemo init code didn't properly
wait until the maemo thread was fully initialized,
leading to dangling pointers when the code called
by pcm_init() tried to access maemo's variables.
Fix it by refactoring the "very fast shutdown" semaphore
to wait until maemo is initialized in any case.
This should also fix very rare rockbox crashes
on startup that I got once a year or so.
The new code has been tested by a script that
starts and kills rockbox after one second.
Change-Id: I464efce5f2b71ca869c72a5bc578555b8022e459
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
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>
This changes iBasso DX50/DX90 config from CHARGING_SIMPLE (Simple, hardware
controlled charging (CPU cannot read charger state but may read when power is
plugged-in) to CHARGING_MONITOR (Hardware controlled charging with monitoring
(CPU is able to read HW charging state and when power is plugged-in)).
Not really usefull at the moment, since USB connection (charging) is not (yet)
gracefully handled for iBasso devices.
Change-Id: I55da81b10637d4de88d713ea5eba08eb59bc629f
Reviewed-on: http://gerrit.rockbox.org/1010
Reviewed-by: Michael Giacomelli <giac2000@hotmail.com>
