GCC 4.9 always emits assembly with divided syntax. Setting unified
syntax in inline assembly causes the assembler to complain about
GCC's generated code, because the directive extends past the scope
of the inline asm. Fix this by setting divided mode at the end of
the inline assembly block.
The assembler directives are hidden behind macros because later
versions of GCC won't need this workaround: they can be told to
use the unified syntax with -masm-syntax-unified.
Change-Id: Ic09e729e5bbb6fd44d08dac348daf6f55c75d7d8
old_chunk has already been unpinned therefore the address
could be incorrect
NULL will ensure buflib_shrink uses the same start address
Change-Id: I9371e4f8263c6e5bf769108a8558dc938d4c8b87
find_font_index can use font_filename_matches_loaded_id()
font_path_to_glyph_path doesn't need strcat
Change-Id: I8d1d36a68abbc700078d651eed930035641b6240
stupid bug on my part font_filename was pointing to a movable
alloc therefore that data could be moved out from under the returned pointer
instead pin the internal calls to core_get_data and
remove font_filename in favor of a function that checks if a
filename matches the loaded font as this was all it was used for anyway
Change-Id: Iebb47ffe3f81aa9d5e3968975f26d64283633ffc
only alloc enough space for the path instead of a fixed buffer
round up the path buffer size to slightly more thna the longest
common path length to reduce reallocations
Change-Id: I51b8b17584d6a905ea3a66a7c38b7b1b9da2e786
Apparently a response is coming out of nowhere and tripping this
check. I can't be bothered to look into it; it would be better to
just update the ARC USB driver to the new control request API...
Change-Id: Ic5062443e060534f170d3afe17c00d3c25d1d3bd
The perceived loudness change of a change in volume depends
on the listening volume: at high volumes a 1 dB increment is
noticeable, but at low volumes a larger increment is needed
to get a comparable change in loudness.
Perceptual volume adjustment accounts for this fact, and
divides the hardware volume range into a number of steps.
Each step changes the dB volume by a variable amount, with
most of the steps concentrated at higher volumes. This
makes it possible to sweep over the entire hardware volume
range quickly, without losing the ability to finely adjust
the volume at normal listening levels.
Use "Volume Adjustment Mode" in the system settings menu
to select perceptual volume mode. The number of steps used
is controlled by "Number of Volume Steps". (Number of steps
has no effect in direct adjustment mode.)
It's still possible to set a specific dB volume level from
the sound settings menu when perceptual volume is enabled,
and perceptual volume does not affect the volume displayed
by themes.
Change-Id: I6f91fd3f7c5e2d323a914e47b5653033e92b4b3b
The newer players have some changed hardware, but most importantly
the line out now appears to be routed through the stereo switch
instead of being hardwired directly off the DAC.
Disable muting the headphone amp, enable switching the stereo switch,
and rename some of the GPIOs to be more generic since the DAC,
headphone amp, and stereo switch all appear to have changed.
Change-Id: I220fe5e37bcbcd959b544183e1fcf70673a83c13
It seems connecting an iPod Video to a Mac triggers the null
request check, resulting in a panic. Ignoring the error with
a bare return "fixes" it and allows the iPod to connect. This
isn't ideal though, because it could silently introduce bugs
on other targets.
The likely cause of this is the host sending control requests
too fast, or a driver problem (the Video uses the ARC driver,
which is still on the legacy interface), with multiple requests
getting queued at once. Since the USB core expects to deal with
only one request at a time, the second response trips the check.
Try to handle this situation a bit more gracefully by detecting
overlapped requests and returning a STALL to the host when it
occurs. At this point the USB stack is able to safely handle a
new request.
Link: https://forums.rockbox.org/index.php/topic,54414.0.html
Change-Id: I9a2b7e35620ff540ebdb39f81671377062a4917d
These are more efficient than separate pin/unpin calls because
pin count increment and decrement can be done cheaply when the
data pointer is known.
Secondly, pinned access can be made safe against preemption by
hardware interrupts or other CPU cores; buflib_get_data() can't.
This makes it more useful under different threading models and
for SMP targets; both of which are not particularly relevant to
Rockbox now, but might be in the future.
Change-Id: I09284251b83bbbc59ef88a494c8fda26a7f7ef26
This is intended for improving the effectiveness of tools like
ASAN when debugging memory errors in the sim. It's not meant to
be a serious allocator for hosted targets.
Enable it by changing the buflib backend in config.h.
Change-Id: I0cf23cefa47ee35dede7b49e0e5b72dac60e8d3e
To minimize code duplication between buflib backends move the
public part of the API to buflib.h. Also rewrote documentation
for the whole API.
Change-Id: I4d7ed6d02084d7130cb41511e63c25ec45b51703
Gate buflib_get_data() checking, debug printing, and buflib
integrity checks behind individual defines in buflib.h, and
turn them all off by default. If needed, they can be turned
on manually when compiling.
The buflib debug menu is only available if debug printing is
enabled, so after this commit it will no longer be included
in normal builds -- it isn't very useful to end users.
Change-Id: Iab25b7852bc7c5592ce04c9c45762046a87d5bc3
Removing the variable-length name in the middle of buflib metadata
makes it a lot easier to deal with.
Change-Id: I6eaf236c2285cae40fb6ff0fa5acf827972cdd8b
The CRC is a fairly useless safety check because we already
have specific checks to validate the metadata, and CRCs are
only verified before calling the move callback. Removing the
check should not significantly reduce buflib's robustness.
Change-Id: Ica99bd92fc514819b4fd9f359b4272e581020f75
Remove the name handling code, but leave the allocation structure
otherwise untouched; it's as if all callers provided a NULL name.
The public API still accepts names but names are no longer stored
or returned.
Change-Id: I6c4defcdfd255774f02030949a0fd731477e6a54
Naming your allocations is more of a debugging feature; it's a
bad idea to abuse this feature for storing some random string.
The font code does exactly that to remember the path used to
load a font, and it's the only code that uses buflib names in
this way.
Store the path inside the font allocation instead as a regular
char array. For simplicity it's MAX_PATH sized, so this'll use
a bit more memory than the buflib name method, maybe 1-2 KiB if
a few fonts are loaded.
Change-Id: Ie286a1a273d6477af9e5d3f76e0534b62f72e8f7
It's usually only called from init() in main.c, so this is safe.
There is one more call in system-dm320.c from system_init(), but
that's also "safe". I don't know if it's okay to call i2c_init()
twice, but presumably it works...
Change-Id: I9c1cd918d162d9955f7cf03209e836cbd5e30c57
On single-core targets, system_init() is only called from init()
in main.c, which is also INIT_ATTR, so this is safe.
Multi-core targets additionally call system_init() from cop_main(),
which isn't marked INIT_ATTR. I'm fairly certain that it would be
safe to add INIT_ATTR to cop_main() with a bit of refactoring, but
I don't have a way of testing it. So for now, leave INIT_ATTR off
for multi-core targets.
Change-Id: I8fe4358f975880ca317d46bda01d7d9db529d3e3
chunk_alloc allows arrays (or any data) to be allocated in smaller chunks
you have to save the indices..
variable data will have variable indices you need to
store these as [chunk_alloc] doesn't keep track
if you have a fixed size for each
alloc you can do indice / sizeof(data)
or index * sizeof(data) to convert
Lots of debug stuff still in and it needs optimization
User provides chunk_size and max_chunks
max_chunks * struct chunk will be allocated at start
with (1) chunk_size allocation initially
alloc_chunk() with size = 0 shrinks the last allocation to the size of the data used
add OOM checks on buflib_alloc -- oops
move bytes available to the header -- less memory per chunk & better alignment
keep track of the current in use chunk index -- should speed things up a bit
Now allows:
realloc chunk header
larger allocations than chunk size
reallocs smaller than existing will shrink the current array
rather than alloc a new and copy data
Comments welcome :)
Change-Id: I8ed170eef73da95da19430a80b32e5debf0c8276
Fixes a bug introduced by commit 5d0c382a59 that caused graphical
corruption on anti-aliased fonts.
Change-Id: I6052ca758382bd9a1154d2e2208dee633dd17715
Avoids a harmless out of bounds reads in ASAN that occurs with
malloc buflib. Code size and performance is similar.
Change-Id: I1c674d046b069e64ad8cb6941356f7c568a81e88
fiio m3k native is currently the only player with
defined buttons different from the standard
mapping.
This allows the user to use the keyremap plugin
to specify differing keymaps for their device in the locked state
Change-Id: Ie0b447bba0d5978e8d23fed423df30c794afc6f9
Add context flags to keyremap
CONTEXT_LOCKED
CONTEXT_REMOTE
CONTEXT_REMOTE_LOCKED
--CONTEXT_PLUGIN-- Removed -- Plugins need a custom action list
supplied and a method of supplying them
Change-Id: I5201d275ad0ab6130c2d05d5afb0c450f5c1746c
Add INIT_ATTR to some low-hanging fruit in the X1000 code:
GPIO init, GPIO initial state tables, clock init, and DMA init.
Change-Id: Ia02b20945da1bbed103e2e01eaf60553eb5f72d4
Enable INIT_ATTR support in config.h. Load init code to the
codec buffer, following the convention used by other targets
that support INIT_ATTR.
Change-Id: I8935fbaa100f0013bb328d71c4a49ec2ffafd003
check for invalid userdata by assigning the address of 'invalid_userdata'
this cleans up the functions a bit and removes some extra conditionals
Change-Id: Ic5e13147796e629010a1436eb60042f6550a959c
The font code expects the full path to be stored in the
buflib alloc so this breaks eg. saving the glyph cache.
This reverts commit 2b4a4070c9.
Change-Id: I53844c39b34b14f7c8e5999825c1d012fa3f74dc
As those form factors are typically not runtime removable and as such
expect to always being powered up.
This is an experimental change, and we might revert it if it doens't help
Change-Id: I61187f297866f64589a546352828a0ff8169fa30
HAVE_MULTIVOLUME is a subset of HAVE_MULTIDRIVE
in normal circumstances they are interchangable
but when the internal drive is not found the assumption falls apart
at the moment most of the bootloader are less selective about what drives/volumes
they will mount therefore the volume might not match between what the bootloader
returns for multiboot and what the firmware sees
updating bootloaders will fix this but it should probably be made more robust
at the same time
Change-Id: I93acd4a539894f093211b74b030df3b2c6a0aa11
