Supporting large transfers (>64k) isn't really needed;
the main use case right now is interfacing with an LCD
controller.
Change-Id: I901e5ddb1b4efa9aa650b3e5074537ba785c6d41
Add an optional sequence in the startup code to disable clock
gating when the CPU goes to sleep. Normally the D1 and D3 domain
clocks can be automatically gated when the CPU is asleep, and
because the debug infrastructure is clocked from these domains,
the debugger cannot attach when those clocks are stopped.
Setting some bits in DBGMCU_CR prevents this problem, but will
increase power consumption, hence it isn't enabled by default.
Change-Id: Iba87750371a493adf72655aab86a908ef2702cef
This commit does the following changes:
- Replace buffered io implementation with a simpler, lighter, slightly faster version.
- Turn off both screens when backlight goes off.
- Small change to enable plugins in the folling commit (s).
Change-Id: I45df30be037c3a1686bd85c16c87bcd248db456f
The ZEN V target is the only one which has volume buttons,
but lacks the menu and shortcut buttons.
IMO an independant keymap will make maintenance easier.
Change-Id: Ide79fab629b13eae94946561d99052e570c0e4f2
The layout of 'struct regs' is a bit different on Cortex-M
and start_thread() wasn't updated to match; it was loading
'sp' from the wrong offset.
Change-Id: I57dbef26809821d411dc86e2066a2f53e78a3f2d
According to wps code audio_pre_ff_rewind function should be called
before any rewinding. It stops playback and automatically resumes it
after audio_ff_rewind call
So, let's add audio_pre_ff_rewind to plugin's API
Lua scipts were tested:
```lua
-- has issue with rewinding
rb.audio("ff_rewind", 0)
```
```lua
-- no issue with rewinding
rb.audio("pre_ff_rewind")
rb.audio("ff_rewind", 0)
```
Change-Id: I2ad6b9c396760b2086bc0a28633a1c80c3512739
Original author Melissa Autumn (https://codeberg.org/oopsallnaps/rockbox-hibyos) with contributions from Marc Aarts.
Adaptation to Rockbox standards by Marc Aarts
Change-Id: I09e5af7ba0a75c648e4b9fd424badc2d3665c943
Broke the sim, just above it has..
struct queue_sender_list
{
/* If non-NULL, there is a thread waiting for the corresponding event */
/* Must be statically allocated to put in non-cached ram. */
struct thread_entry *senders[QUEUE_LENGTH]; /* message->thread map */
struct __wait_queue list; /* list of senders in map */
/* Send info for last message dequeued or NULL if replied or not sent */
struct thread_entry * volatile curr_sender;
struct blocker blocker;
};
Change-Id: Ifc7a5fe92ebe5f06c0dc5655ce9725752e606381
sector_t is still 32-bit on most targets, resulting in compile
warnings on debug builds when used with an %llu/%llx format.
Fix by always casting the sector to uint64_t.
Change-Id: I5afc4a0ae170981c304274806e00ac07be232cd8
This tries to access 'struct event_queue->send', but that
is only available if HAVE_EXTENDED_MESSAGING_AND_NAME is set.
This is not defined for bootloaders; this is a problem when
trying to build a bootloader with debugging enabled, because
the misdefined macro is used in some KERNEL_ASSERTs that get
compiled out on non-debug builds.
Change-Id: I334eedcda1ee7047c8dddcb7fa0c9717156f2a0a
Fixes voice not working after booting but before starting music playback
while line-out is plugged in. Doesn't seem to break anything on hw1 or
hw4.
Change-Id: I7b830adeeceae621177c94353e4814aa6ad0e1ec
Turns out I compile-tested stale trees instead of the broken change
Net result is just the simpler MIPS revision (32/64/"classic") lookup rather than
the sub-revision (eg mips32r2 etc).
Change-Id: Ideebe522d29132f00f3769222f3846000b3a89fd
This allows us to easily distinguish between mips32 and mips32r2
(Works at least as far back as gcc 4.9)
Change-Id: I2bcba194fd9cbeedf76cea739252271908bf73d0
These were lifted from the lua plugin.
sdl, doom, puzzles updated to use the exported version
todo: lua, maybe?
also: convert uses of atoi [back] to strtol
Change-Id: I5a1ebbe8d8c99349e594ab9bbbce474e7645b4e9
* Detection of 64-bit Arm v8-a
* Proper detection of integer division support
* always on v7-m, v8-a, v9-a, v8-m.main
* sometimes on v7-a, v7-r, v8-r
* never on v8-m.base v6-m, v6 and older "classic"
* tl;dr: Rely on toolchain preprocessor definition
For the most part these additional variations won't acutally work
for native target builds, but sane -A detection is needed for
"local" builds now. -R detection is left out as it's not likely
to matter.
Change-Id: I8f6a52edc4d14490fc00e2f487406eca701eef02
The touchscreen repeat interval effectively controls the report
rate of the touchscreen to the action code. Touch interactions
are smoother with a faster refresh rate, but the CPU needs to be
fast enough to keep up, or we risk queue overflows.
25fps is the minimum required to appear smooth, and probably all
targets will be able to handle the extra CPU load.
Change-Id: I96dcc80ea2ce8b915ff5682360c2e719b835388d
Add a cleaner API for reporting touch events and deprecate the old
action_get_touchscreen_press() API. The old API is now emulated by
using the new one internally.
Change-Id: I001378e66f9c81806f134f011420d671954fcde2
The only v7-a targets we have are built using the androidndk (with gcc
4.9) but it is possible to perform "self-hosted" builds for eg the
simulator or the sdlapp.
Where this gets messy is the considerable amount of inline arm
asm we have.
Native builds will need considerably more work to support
v7-a processors, but we have to start somewhere.
(Note that this contains parts of commit 508bfabe8, which had to
be reverted due to breakage)
Change-Id: Ia1c8e10d21a976c68fdaae58e4d776854b63186c
They haven't seen any work since 2013, and likely hasn't compiled in at
least a couple of releases -- not that we ever "released" anything for
these targets.
Futhermore, upstream for both has been effectively dead for about as
long, and there's been no user reports of these being used since 2017
(and even then only in passing).
It isn't worth the effort to triage their current state, much less
uplift into something supportable, while the maintenance burden of
keeping these things in-tree can be demonstrated by the diffstat.
Change-Id: Id93bd450679d1b75e2c74295b3ae1548cd241b24
The way the button driver reported touch events was problematic
and made it impossible to detect if a touch started or if it was
a continuation of an existing touch.
Now, the first detected touch event gets BUTTON_TOUCHSCREEN and
all subsequent touch events while the screen is pressed will get
the BUTTON_REPEAT bit set. When the screen is released the final
event will have the BUTTON_REL bit set.
Change-Id: Ia456a22b2180031555a82231c2af32576bc5f2cb
This is a partial revert of a79bdaf46
It caused all sorts of build breakages for misc stuff like the dbtool,
which doesn't include any per-target build directories
Change-Id: I493a33c1859706679972e47c96196223415985d9
They are nearly entirely generic wrappers around ALSA controls, unique
per target, and are ripe for further consolidation.
Change-Id: I05e4a450e3e89e03616906601c4f8fa46200dff5
Several hosted targets read their battery state from a fixed
sysfs path. Get rid of the duplicated code by handling this
common case in power-linux.c.
Some targets use non-standard units in sysfs instead of the
typical microvolts / microamps, so allow the scale factors
to be overridden by the target.
Change-Id: I31dc4ffc7a2d2c066d00a74070f9f9849c1663d0
Our decade+old defaults are reported to trigger a failure on
one user's IHIFI770c and IHIFI960, but work on their HM-603.
Backing CAS latency off from 2 to 3 appears to be sufficient.
What's interesting is that on paper, CL=2 should be easily attainable
due to our max RAM clock of 100MHz, well within the worst-case timings
of the EM639165 SDRAM.
So as an experiment, this code can go back to CL=2 when we change the
CPU+RAM clock speeds. IF this still proves problematic, it will be
removed.
Change-Id: I4a8cfa0563c076e7f25d9599a19b454f590861cd
The introduction of a debounce interval for USB
status by event (see e75a3fb), often resulted in the
FiiO M3K crashing after disconnecting from USB.
Shortening the interval to 10ms appears to fix this,
or make a crash much less likely at the very least.
Change-Id: Ibf1f02779ab1704d9b1c86d39b21648a3e2c4e9d
Creative ZEN lost it's time when shutting down.
The bug was introduced with commit 7f282b9280 (g#2601),
followed by e3f6e9d9f6 (g#2616).
I guarded all persistent register writes with wait loops,
as described in the datasheet.
TODO:
test SONY_NWZE360 and SONY_NWZE370 targets
Change-Id: Ib38ab8691fd1c6e8d0771c1e2eca20dfeb6fc87f
Despite the fact that CE-ATA specifies a minimum logical sector size of
4096 bytes, the low-level tranfer command arguments are specified in
units of 512 bytes. So scale the sector count up and the LBA down.
On CE-ATA devies, the partition table and filesytem is formatted with 4K
logical sectors, so this will be safe.
Change-Id: I959f21f9c72a68ac28aa611d06f8517ca77f0a8c
Default MMC block size is 512B, and the DMA block size must equal
the MMC block size. As we do not negotiate a larger block size,
scale the transfer count up to match the drive's logical sector size.
(CE-ATA mandates a *minimum* sector size of 4K)
Change-Id: I701cbac5c0fa320e8d38ea3333d99257b9b1f560
The DMA xfr size was fixed at 512 bytes, but the count was specified
in terms of the logical sector size (ie 4096 bytes).
Make the DMA size line up with the sector size.
Change-Id: Id9d0088b12775223f8d888f21b19e17c97927570
