IMHO the current name is somewhat misleading:
- usb_drv_send() is blocking and we have usb_drv_send_nonblocking()
for the non-blocking case. This inconsistent naming can only
promote confusion. (And what would we call a blocking receive?)
- Other hardware abstraction APIs in Rockbox are usually blocking:
storage, LCD, backlight, audio... in other words, blocking is the
default expected behavior, with non-blocking calls being a rarity.
Change-Id: I05b41088d09eab582697674f4f06fdca0c8950af
The abiflags data is only used to communicate ABI information to a
program loader -- you can see what info is stored with readelf -A.
Dropping it shaves 24 bytes off of every binary (including plugins).
Change-Id: Iae78eeffe5c840ff67717707fb94821d24aac8ec
Using a macro to put each function in its own .icode-based section
allows us to put the functions in IRAM _and_ have linker GC. This
removes a troublesome #ifdef BOOTLOADER_SPL on the X1000 target.
Change-Id: Ia7b59778f5c36b7970dee4280547e434a1f4fc5a
The X3's line out is a bit hot, at ~4.3Vpp, so allow it to be backed off.
(On my X3, backing it off to -6dB brings Vpp down to ~3.4V)
Change-Id: Iea38ef1c6a1b183d0f8fb4eaf2bf9ed6b350a532
Enable its use in the jz47xx MIPS targets.
(accidently committed g#3249 before making these changes)
Change-Id: I1791946f632901f0c7a94b04b009671aa0d71717
- The range-based cache operations on MIPS were broken and only worked
properly when BOTH the address and size were multiples of the cache
line size. If this was not the case, the last cache line of the range
would not be touched!
Fix is to align start/end pointers to cache lines before iterating.
- To my knowledge all MIPS processors have a cache, so I enabled
HAVE_CPU_CACHE_ALIGN by default. This also allows mmu-mips.c to use
the CACHEALIGN_UP/DOWN macros.
- Make jz4760/system-target.h define its cache line size properly.
Change-Id: I1fcd04a59791daa233b9699f04d5ac1cc6bacee7
* pcm_get_bytes_remaining()
* pcm_calculate_peaks()
* pcm_get_peak_buffer()
Nothing in-tree uses these at all (except for the lua plugin wrapper)
Change-Id: I971b7beed6760250c8b1ce58f401a601e1e2d585
Nothing in the core has used it for some time. It's exported to the
plugin API but the last plugins to use it were switched to the mixer API
back in 2011.
This allows us to get rid of pcm_play_dma_pause() from all audio drivers
Change-Id: Ic3fa02592316f84963e41d792d1cabb436d1ff6b
Whether or not this is correct depends on how the source material was
mastered, digitized, and/or encoded. There is no setting appropriate
for everything.
Eventually I'd like to make this configurable, but I'd want to have it
shared with more than one target first.
Change-Id: I20a0eff4b3dc2517c33db49d4f72e85bf81d1ca6
Note: PCM mix buffer sizes are _way_ too small for these high bitrates
(We really need to make the mixer stuff use dynamic buffer sizes based
on the bitrate. Maybe pre-allocate a max size based on upper bitrate limit,
but use only part of it at lower bitrates? So we can have sane latency..)
Change-Id: Id7b4afd73dba7f1ffb84b2e1c016859fae5d6835
Can be disabled at runtime by setting hold switch.
Boosts sysbench sequential write performance by 34-58%
Change-Id: I060c9d7dddc1b448f18aa46af8f8aff046e07843
* DMA Bulk IN (ie our TX) results in sequential transfers 33-68% faster.
* DMA Bulk OUT (ie RX) is mostly stripped out due to complete brokenness.
* Interrupt and control endpoints remain PIO-driven.
Other improvements:
1) Use consistent endpoint references (no magic numbers)
2) Greatly enhanced logging
3) DMA support can be compiled out completely
4) Setting lockswitch will disable all DMA operations at runtime
5) Much more robust error checking and recovery
Change-Id: I57b82e655e55ced0dfe289e379b0b61d8fe443b4
Fixes deficiencies with the button system on the X3
The x3 has an interesting button layout.
Multiple key presses are NOT supported unless
[BUTTON_POWER] is one of the combined keys
As you can imagine this causes problems as the power button takes
precedence in the button system and initiates a shutdown if the
key is held too long
instead of BUTTON_POWER use BUTTON_PWRALT in combination with other keys
IF using as a prerequsite button then BUTTON_POWER should be used
Multiple buttons are emulated by button_read_device but there are a few
caveats to be aware of:
Button Order Matters!
different keys have different priorities, higher priority keys 'overide'
the lower priority keys
VOLUP[7] VOLDN[6] PREV[5] NEXT[4] PLAY[3] OPTION[2] HOME[1]
There will be no true release or repeat events, the user can let off the
button pressed initially and it will still continue to appear to be
pressed as long as the second key is held
Tree scrolling is PLAY+NEXT or PLAY+PREV
Change-Id: I88dfee1c70a6a99659e8227f5becacc50cc43910
Group commands for a bit more speed
bitdelay was not being inlined
lower bitdelay to 12 cycles
Clean-up magic numbers
Change-Id: Ifeb57a5532807a598f1ec5e1c55f03e4aa1e133f
* Increase audio buffer size to better handle IRQ latency (256->2048)
* Ensure DMA engine is idle prior to starting transfers
* Set AIC to repeat last sample in case of underflows
Change-Id: I9c45c20481ee072e5882b7586fb7d50bd8ef2f35
Based on code originally written by Amaury Pouly (g#1789, g#1791, g#1527)
but rebased and heavily updated.
Change-Id: Ic794abb5e8d89feb4b88fc3abe854270fb28db70
only check button values with adc when buttons are actually pressed
battery level check frequency is now around 30 seconds
switched to polling for the battery voltage w/ timeout
Ifdef functions Allow BACK OPTION PLAY to be the first of a two key combo
Change-Id: Icb48d62ac8d82b4dc931df5e1c5b4a84a9a69772
Back off to 480MHz [max] clock, bus/mem clock of 120MHz.
576 is unstable on at least one unit, and 528 still glitches.
Change-Id: I020e48532524e739f3bfa42bed570381ccd34959
