add needs_cpu_boost field to usb_class_driver and manage boost state in
usb_core, similar to needs_exclusive_storage.
Change-Id: Ieb0cd7bedda5b24bb0d209d5ce907db30f4815db
this is required to make hid endpoint of iap class driver work,
especially on ipodvideo(arc).
at least for arc, it is required to set mps as 64 instead of 512 on
highspeed, or some accessories ignore incoming hid reports.
Change-Id: I242060faced28a66204146a9c36ef10626d6d265
add class driver source files.
also register iap audio sink.
usbstack/iap/libiap directory is imported from libiap.
Change-Id: I776c5caec33fe9efadc448e2e3b37d500bf19c9f
Perhaps this was needed in the distant past, but these days
GCC provides a working <stdint.h> for freestanding targets.
Change-Id: I4f02f12058a13b6a086ccc52f02a12ce21a986c1
Themes like Adwaitapod, Themify, or FreshOS have
custom "lock screens" that are drawn on top of the
UI viewport.
Request a full skin update when unlocked, so you don't
have to press a button to make the hidden UI viewport
appear again.
Change-Id: Idf5023b4e12f7aea1cd7a2e9d9ab2f754387dc48
Stop the lock indicators on the SBS from lagging
behind their actual state when lock notifications
are disabled.
Request immediate skin update in button loop, so
the device doesn't feel laggy.
Change-Id: I42955f65d9ad4ca9196549d806538d1badb5f79d
The o32 ABI requires at least 8-byte alignment. This fixes
the float formatting weirdness seen in quake (FS#13821).
Change-Id: I4b587946884d7b35cef420e607c7e127664849e2
On FS#13821, a test build with -fstack-protector-all
(which adds 4 bytes of stack to each function, roughly)
overflowed the dircache stack on the Hifiwalker H2.
In my own testing, the dircache thread hit 94% stack
use on the Fiio M3K using the same settings.
That seems a bit too close to the limit, especially
since the dircache uses recursion and might consume
more stack space for deeply nested directories.
Adding 768 bytes should provide enough of a safety
margin. This increases the stack size from 1.25k to
2k on most targets, including all X1000 targets.
Change-Id: I900c19da9fb33f539d02b00830aedeb15c7449e2
-fstack-protector only needs a small amount of runtime
support to work on native builds. It increases code size
by ~1.5% on ARM/MIPS; -fstack-protector-strong adds 3-4%.
This is disabled by default and must be enabled by passing
'--with-stack-protector' to configure.
Change-Id: If952e711d3673c9b469895f08c7bff70b3d95df6
CC firmware/pcm.c
firmware/pcm.c: In function ‘pcm_switch_sink’:
firmware/pcm.c:311:38: warning: array subscript 1 is above array bounds of ‘struct pcm_sink *[1]’ [-Warray-bounds]
311 | struct pcm_sink* old_sink = sinks[cur_sink];
| ~~~~~^~~~~~~~~~
firmware/pcm.c:79:25: note: while referencing ‘sinks’
79 | static struct pcm_sink* sinks[PCM_SINK_NUM] = {
|
PCM_SINK_NUM is 1, and cur_sink is initialized to 0. It can never be set
above 0. cur_sink can never be >= PCM_SINK_NUM, ie 0, but for some reason
the compiler thinks otherwise.... sometimes.
This only shows up on native ARM builds with GCC9.5.0
Change-Id: I1aa731a4ee21c46a264c8b70833e3b43e777e8a7
Required for dynamic inputs (like bluetooth).
Files are now opened with O_NONBLOCK, and inputs are automatically removed on poll errors.
Also added call to close all devices on power off.
Change-Id: I8991bdb881fdc00135d1fd5b01ac900c0b007aeb
The recent pcm_mixer changes caused us to overflow IRAM by a whopping 8
bytes. This can _probably_ be mitigated with some clever reworking but
we were clearly already on the hairy edge.
Future pending changes are likely to increase IRAM pressure so even if
we solve this issue the odds are it will reappear at a future point.
(the ipod4g's framebuffer is 5KB. This doesn't affect the mini2g as its
framebuffer is under 4KB, and the ipodcolor doesn't put its framebuffer
in IRAM at all)
Change-Id: I2f50d998e969a706cc9d3a0e057cf8e6c303c9b4
some targets can process requests fast enough without dedicated
batch api implementation.
provide generic implementationn for such targets.
Change-Id: I152681441e70e0e98396274d9305d371d2bbfbe3
in order to implement iap digital audio interface, we have to send
a pcm packet every usb frame i.e. 1000 packets per second.
this rate can't be achieved with current standard request-response design,
even with fast_completion_handler.
this is why this new api is needed.
Change-Id: Id3d7dd037660871e2bdb69656f63ff13280c3804
This way all paths to setting the volume respect the limits, instead
of only callers of setvol(), which only applies to (some?) interactive
paths.
Change-Id: Ia8ece22aafcb04df33021071cb933eaeb1146502
firmware/pcm_mixer.c:36:35: warning: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709551615’ to ‘4294967295’ [-Woverflow]
36 | static unsigned int mixer_sampr = -1UL;
|
firmware/pcm_mixer.c:269:21: warning: comparison is always false due to limited range of data type [-Wtype-limits]
269 | if (mixer_sampr == -1UL)
| ^~
So drop the 'L' and everything is peachy.
Change-Id: I9440d3300931be229c6c4b01bdc1d09b55c34d88
All that matters is that the _current_ sink is ready, not all possible
sinks. When switching sinks we will need to ensure tehy are initialized
before switching over.
Change-Id: I341f7e9dcb4e2add4d0b292b68b69eb08dec0194
Change the SAI FIFO threshold so that it is always
kept topped up at maximum; DMA needs to do single
transfers to the peripheral now. Ignore FEIF errors
since they seem to occur constantly with this setup
(though it's not exactly clear why this happens).
FEIF only indicates that the SAI made a DMA request
while the DMA FIFO is empty, which isn't a fatal error.
The DMA channel will simply service the request when
it is ready.
Keeping the SAI FIFO constantly full increases the
overall timing margin before underrun so losing the
FEIF info isn't a big deal in practice.
Change-Id: I16eb1cbb17039db76938bd86c4921b8060c83556
The purpose of the mutex is to make it possible to switch pcm sinks
safely, but pcm_play_lock/unlock and pcm_set_frequency need to be
called from IRQ context which is fundamentally incompatible with
our mutex implementation.
The proper path forward will be to promote the counter-based per-sink
lock/unlock implementation to the pcm core, and only allowing sink
switching when the counter is 0.
In the mean time, just remove sink_mutex entirely as the sink switching
code has yet to be committed.
Change-Id: I029459d7ec6ea47c6e2b8fce52d203129a282832
- Move all devkitpro includes before the Rockbox ones so that the macros which are both conflicting and unused can be undef'd
- Remove unused result variables
- Exclude an unused function from being compiled for this target
- Fix hex number formatting
- Fix the return value of dummy functions
- Fix macro redefinition in the plugins keypad config
- Remove duplicate button mapping
- Turn off -Wchar-subscripts as it's already handled in Rockbox's ctype.h
Change-Id: I3f5a3d492c585f233277a380feaea5fe877a044f
It is required to call gfxExit() before exiting the app if gfxInit() was previously called. Otherwise, the GSP thread continues to run after the stack is invalidated. The missing code is already in lcd_shutdown(), but it was never called because HAVE_LCD_SHUTDOWN was not defined for the ctru target.
Change-Id: I8999df6372cd593c5b52478028ad7421b23d5f92
Confirmed on iFlash-modded ipodvideo, USB mass storage connections
frequently fail with bus resets during mount on macOS, and trigger
"reset high-speed USB device" errors on Linux during sequential
reads.
The root cause is: storage_read_sectors() calls yield() via
ata_wait_intrq(), which switches to the main thread running
handle_usb_events() loop. This calls send_event(GUI_EVENT_ACTIONUPDATE),
triggering LCD redraw that takes approximately 110ms. This stalls the
ATA DMA completion, causing the USB bulk transfer to time out from the
host's perspective.
This commit removes the yield to prevent the reading thread from being
preempted by the lengthy LCD redraw during DMA completion.
This also improves sequential read throughput from ~13MB/s to ~18MB/s.
Change-Id: Ia552f97aa0169c93c4f21e250d13dc3a626661d4
* Terminating record of the max unicode codepoint (0x10ffff)
* Add in Arabic diacritic marks in the 0x10efa..10efff range
This is currently disasbled due to it effectively doubling the
size of our diacritic table. The diacritics added are unlikely
to be seen in practice as they are used only in some formal
Quaranic contexts. If we identify other diacritic marks above
0xffff, then we can turn this code on.
Change-Id: I50c2eace18c70be6fe7199fccab190e7da401089
