Apparently I got the "just-in-case" RXFIFO purge in there before the
RXFIFO was enabled, causing severe hardware spasms.
Change-Id: I2ea4b6d28e06372b61cb3f21ab2fce71dd408213
Additional status callback is added to pcm_play/rec_data instead of
using a special function to set it. Status includes DMA error
reporting to the status callback. Playback and recording callback
become more alike except playback uses "const void **addr" (because
the data should not be altered) and recording uses "void **addr".
"const" is put in place throughout where appropriate.
Most changes are fairly trivial. One that should be checked in
particular because it isn't so much is telechips, if anyone cares to
bother. PP5002 is not so trivial either but that tested as working.
Change-Id: I4928d69b3b3be7fb93e259f81635232df9bd1df2
Reviewed-on: http://gerrit.rockbox.org/166
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested-by: Michael Sevakis <jethead71@rockbox.org>
FreeBSD apparently sends a SET_ADDRESS first, which confused our code.
This patch fixes that, and also simplifies the connection handling a bit.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31582 a1c6a512-1295-4272-9138-f99709370657
* Introduce CONFIG_BATTERY_MEASURE define, to allow targets (application)
to break powermgmt.c's assumption about the ability to read battery voltage.
There's now additionally percentage (android) and remaining time measure
(maemo). No measure at all also works (sdl app). If voltage can't be measured,
then battery_level() is king and it'll be used for power_history and runtime
estimation.
* Implement target's API in the simulator, i.e. _battery_voltage(), so it
doesn't need to implement it's own powermgmt.c and other stubs. Now
the sim behaves much more like a native target, although it still
changes the simulated battery voltage quickly,
* Other changes include include renaming battery_adc_voltage() to
_battery_voltage(), for consistency with the new target functions and
making some of the apps code aware that voltage and runtime estimation
is not always available.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31548 a1c6a512-1295-4272-9138-f99709370657
Enabled a PMIC event where it should be disabled. Used constant from wrong enum
to get sense bits (??) which messed up main charger detection.
Also remove an obsolete struct declaration.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31536 a1c6a512-1295-4272-9138-f99709370657
Dispense with "pmic" thread and process PMIC events directly within ISR. Add
sense bit reading as part of the handling.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31528 a1c6a512-1295-4272-9138-f99709370657
Synchronous cable read is still required because the timing of the receipt of
the cable event cannot be known for sure-- basically it introduced a thread
race between main and pmic. If a keypress is desired instead to enter BL USB
mode a la AS3525, then it's possible to remove that.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31510 a1c6a512-1295-4272-9138-f99709370657
Might as well rename spi_enable_module to spi_enable_node for consistency
as well so long as I'm being picky.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31442 a1c6a512-1295-4272-9138-f99709370657
Unify spi_enable/disable_module into one spi_enable_module call for API
consistency's sake with I2C driver.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31441 a1c6a512-1295-4272-9138-f99709370657
Nick some aspects from the as3525 ascodec driver to improve throughput in
the beast's SPI communications by switching tranfer descriptors to the
caller's stack and getting rid of thread synchronization.
Fix a bug that suddenly became obvious that could permanently stall the SPI
driver because all data could be shifted out before the interrupt could get
serviced. In that case, it needs a kick to restart it. Should probably put
the SPI interrupt priority above DVFS.
A tweak to the event registration interface to simplify it.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31353 a1c6a512-1295-4272-9138-f99709370657
Massage the way it interfaces a bit to make things more flexible.
The chroma_buf scheme on Sansa Connect and Creative ZVx calling the
lcd_write_yuv420_lines implementation in lcd-as-memframe.S with five params
with a chroma buffer that the function can't use wouldn't work anyway so just
have them use the stock implementation (really, how was that working?).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31335 a1c6a512-1295-4272-9138-f99709370657
For this commit: Sansa e200v1, Gigabeat F, Gigabeat S and Mini2440 are
changed over. Quite a number of other targets probably can be as well.
General LCD code is moved out of the target drivers into
drivers/lcd-memframe.c.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31311 a1c6a512-1295-4272-9138-f99709370657
* Remove THREAD_ID_CURRENT macro in favor of a thread_self() function, this allows thread functions to be simpler.
* thread_self_entry() shortcut for kernel.c.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29521 a1c6a512-1295-4272-9138-f99709370657
