Logic left over from before switching from NULL-terminated to
counted strings would prevent a single-byte tiny free block gap
from being properly reclaimed into free string bytes.
Due to rarity, not as disasterous to functionality so much as
wrong.
Change-Id: I68e0875b04bb0ab6cdead0fdf535144b9c1bc13e
On STMP3700 there is no dedicated speaker amplifier but speaker is always on
lineout so it makes sense to report volume and power down of lineout.
Change-Id: If666bccf36d3a5ecc6d892823522d023f3206184
On PCM record initialization, an unknown clockgate is enabled instead
of the I2S clockgate. This bug does not produce incorrect functionallity
because the right clockgate is already enabled on PCM playback
initialization.
Change-Id: I97a3a4a6f12131e492c1431359a0a976b68014be
ll_insert_next() and ll_remove_next() can be done more elegantly
by adding a level of indirection to reference the 'next' pointer.
Change-Id: If3ab2bc2a659b517c793749cfa9088938ae08d0d
Some changes in behavior were made with filesystem code commit
for the sake of compatibility that changed expected behavior.
* Restore substitution of drive spec in fully-qualified DOS paths
with the playlists's volume spec (or root on univolume targets).
Drive-relative paths of the form "c:foo" (no separator after
':') will be treated as purely relative.
* Restore old behavior of preserving leading whitespace in the
source path and trimming only trailing tabs and spaces.
* Multivolume: Volume substition on fully-qualified UNIX/RB paths
has NOT been reintroduced (and perhaps wasn't intended in the
first place). They will not be modified because there is no
ambiguity to resolve. Doing so would prevent a playlist on
external storage from referencing a file on main storage without
qualifying it with "/<0>...".
* Plain relative paths are and always have been interpreted as
relative to the location of the playlist.
Change-Id: Ic0800cea79c59563b7bac20f8b08abb5051906c7
The ZEN X-Fi Style doesn't have an updater like the other stmp targets but at
least the stub enables rebooting to the OF.
Change-Id: I630653a37b94b77210ffdd0d30e1748b13eca96a
There are lot IRQ and most are unused most of the time, this is annoying on
devices with small screens.
Change-Id: I7f3453f2768b8e35a5a367fbcf1e4cf3cf73bcd7
Those new statistics give the maximum time an IRQ took and also the total
time spent in IRQ, for each IRQ. Hopefully those do not take took much time
or space to collect. If this is the case, it can be enabled in debug builds only
the future.
Change-Id: I05af172897c5cb7ffcc9322452f974d8f968e29d
The IRQ handler saves registers on the IRQ stack, saves the old PC to imx233
HW_DIGCTL_SCRATCH0 register and switcht to SVC for the actual handling. The
old code had a problem in that if the unwinder is called during the IRQ (for
example by the watchdog), then __get_sp() will use SPSR_svc to discover the
previous mode, switch to it and recover SP. But SPSR_svc is invalid, it should
be SPSR_irq but we switch from IRQ to SVC mode. The new code copies SPSR_irq
to SPSR_svc in IRQ to fix this problem. It also saves/restore SCRATCH0 in
case I one day renable nested interrupts or use SCRATCH0 for other purposes.
I also changed the old watchdog code to call UIE directly instead of trying
to make the code crash with a SWI.
Change-Id: Id87462d410764b019bd2aa9adc71cb917ade32e3
Document 3D depth range. Fix mismatch in recording volume: the displayed volume
is completely off the chart
Change-Id: I4c363f369e5d72f332391a6f96457b4e450404f9
The old code made the setting appear as 0dB, 1.5dB, 3dB and 4.5dB when
in fact it is 0dB, 3dB, 4.5dB and 6dB. This commit clarifies the code and
also fix this at the same time. This imx233 3D enhancement is complete crap anyway
but now you can satisfy yourself with 6 dB of pure crap, clearly an enhancement.
Change-Id: Ia3e088987c1ff0cdde228905ff70f46476a499a2
Everytime I use it, I get highly confused because it's complicated and
undocumented. The code is spread all over the place and some targets clearly
use incorrect values. This is the first step of a series to cleanup audio settings
and document it properly.
Change-Id: I20cb7af2bfa33986cb8b0bf8573f17a92227f893
This commit adds the necessary code in the dualboot stub (bootloader) to
let rockbox control the boot process. In particular, rockbox can now choose
if the next boot will be normal (boot rockbox or OF on magic key), to OF
or to updater.
The intents (to be added in follow-up commits) are:
1) Let the user more easily reboot to the OF. On some targets it is not trivial,
especially in USB mode.
2) Automatically reboot to updater when the user drop firmware.sb at the root
of the drive (currently, the user needs to do that in OF USB mode)
3) Document this OF magic
Change-Id: I86df651dec048c318c6a22de74abb8c6b41aa9ad
This clearly fixes recording on targets where the bias pin was wrong. It may
also improve recording on targets where the bias voltage was wrong. I was unable
to find those parameters on the ZEN Mozaic, which fallback to default values.
Change-Id: Ifb5f823c9cbd01f0d9a80fa5d49d93972c8b7cfe
For some reason, there was a mismatch between the setting (decibel) and the
audiohw code (centicel). This resulted in a gain divided by 10. This may
explain why some people experienced low volume with the mic on the fuze+.
Change-Id: I138ac18dd93c36f43a7dfce735efc826405c598c
Also clarity parts of the code. The old code suffered from two defects:
- it was very unclear because it made changes to whole registers
(using as3514_write) instead of fields (using as3514_set/clear/write_masked).
Also the routing code was spread accross several functions which made it hard to
follow.
- it did not properly reroute audio on monitor changes. In particular, the following
could happen: when switching from DAC to radio, the code would fail to clear
SUM_off, resulting in a weird situation where the main mixer was off
(SUM_off) but the headphone where using the main mixer as input. Incredibly this
worked anyway (at least on AMSv2 and YP-R0) but resulted in strange volume gaps
between DAC and radio mode.
Change-Id: I7826835fdb59c21f6483b223883ca9289e85caca
Based on emCORE.
Low level functions that do not depend on Rockbox kernel,
intended to be used by the bootloader, dualboot-installer,
RB drivers or other .dfu tools.
Change-Id: I3c616ded42260c6626bda23b7e580791981df61d
Based on emCORE.
Low level functions that do not depend on Rockbox kernel,
intended to be used by the bootloader, dualboot-installer,
RB drivers or other .dfu tools.
Change-Id: Iad369627b55bf1778eab437424072f1a653e4db6
- Some rewrite with the intent to get ride of these random errors
appearing on some builds/devices (not much noticeable on RB but
can ruin bootloader builds).
- Error handling (ACK).
- IIC clock increased to be the same as in OF.
Change-Id: Idf8cfa3c230a0a61ec9c879bf6f0ea8b061a4607
Add code to read USB D+/D- and accessory ADCs, it is shown in HW
debug menu, might be useful in future for RB and/or the bootloader
to identify external USB chargers.
Change-Id: Ia48ca5e06bb7ddc52bb55abedde6734653ce8dba
Based on g#844 and g#949, it is intended as a replacement for the
current s3c6400x USB driver.
The DesignWare USB OTG core is integrated into many SoC's, however
HW core version and capabilities (mainly DMA mode, Tx FIFO mode,
FIFO size and number of available IN/OUT endpoins) may differ:
CPU targets HW ver DMA NPTX FIFO FIFO sz #IN/OUT
-------- ------------- ------ --- --------- ------- -------
as3525v2 sansaclipplus 2.60a Yes Dedicated 0x535 4/4
sansaclipv2
sansaclipzip
sansafuzev2
s5l8701 ipodnano2g 2.20a Yes Shared 0x500 4/5
s5l8702 ipod6g 2.60a Yes Dedicated 0x820 7/7
ipodnano3g
s5l8720 ipodnano4g ? ? ? ? ?
Functionality supported by this driver:
- Device mode, compatible with USB 1.1/2.0 hosts.
- Shared FIFO (USB_DW_SHARED_FIFO) or dedicated FIFOs.
- No DMA (USB_DW_ARCH_SLAVE) or internal DMA mode.
- Concurrent transfers: control, bulk (usb_storage, usb_serial) and
interrupt (usb_hid).
Actually this driver is not used by any CPU, it will be enabled for
each individual CPU/target in next patches.
Change-Id: I74a1e836d18927a31f6977d71115fb442477dd5f
Apparently I simply forgot to calibrate it when the port was done and the
current values are just plain wrong, especially for the charging curve.
Change-Id: Ied3cafa52f31f182f953714e28edc4c5e891255f
There are two very suspicious things in the power off code:
- it does not properly unlock the power register, so it should fail (!)
- it does not disable sw/hw watchdog so if register fails, the device will
most probably crash horribly because of the watchdog
I don't even understand how it worked before.
Change-Id: I9f3f94bd012e52c3b50cd5b658d68b5eb907f79b
