HiFi E.T. MA8 is almost the same as MA9 except
another DAC(pcm1792 in ma8, df1704 in ma9).
MA8 has ILI9342 lcd, MA8C has ILI9342C lcd.
Change-Id: If2ac04f5a3382590b2a392c46286559f54b2ed6a
The only difference between this target and HiFi E.T. MA9
is display driver (ILI9342 in MA9 and ILI9342c in MA9C)
Change-Id: Icc3d2490f850902a653175360f12283f3708bbb7
Enable simulator for the target ypr0 to
be built and used.
Change-Id: I1b080f07ab90f5c4856881d08ad70e1053bbb0c0
Reviewed-on: http://gerrit.rockbox.org/618
Reviewed-by: Frank Gevaerts <frank@gevaerts.be>
Target that have a touchpad/touchscreen should disable it while
being locked (In order to avoid LCD to drain battery power due to
"key locked" constant reporting messages. If they a have a keylock
button this was already handled at driver level. If not (e.g. fuze+),
they will have to implement a switch at driver level that action.c
can operate on softlock.
This patch does the following for any target having a touchpad
or a touchscreen and no HAS_BUTTON_HOLD (ie any softlock target)
1) it implements the code to call button_enable_touch(bool en) in
action.c.
2) button_enable_touch is implemented in button.c and call
either touchpad_enable or touchscreen_enable
3) those two function are implemented respectively in touchscreen.c
and a new touchpad.c file. They provide a generic way to silents touch's
device and call a function at driver level where target specific code
can be implemented if possible/needed (for power saving for instance).
Those function name are touchpad_enable_device and touchscreen_enable_device
4) we implement an empty function at driver level of targets that need it
to have them still being able to compiled.
Change-Id: I9ead78a25bd33466a8533f5b9f259b395cb5ce49
Reviewed-on: http://gerrit.rockbox.org/569
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
The idea is to share loading code between bootloaders and rolo().
Change-Id: I1656ed91946d7a05cb7c9fa7a16793c3c862a5cd
Reviewed-on: http://gerrit.rockbox.org/190
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
The driver is current unused and very minimal. It can used on
targets which have an accessible UART port and it will be used on
some creative targets as backlight control.
Change-Id: Id710d63574aadb0a2d7327b03187506b469470b1
Based on FS#9920 by Ryan Press with changes to selection logic so
that it works on my iPod Photo. Should also work on iPod Color/4G
and Mini2G. Moved all target specific code from
firmware/drivers/serial.c into new file
firmware/target/arm/pp/uart-pp.c in the same manner as other
target specific uart code.
Update to fix build error on ipodmini2g by adding defines in config file.
Removed unwanted whitespace
Tested on iPod Photo.
Change-Id: Ia5539563966198e06372d70b5adf2ef78882f863
Reviewed-on: http://gerrit.rockbox.org/455
Reviewed-by: andypotter <liveboxandy@gmail.com>
Tested-by: andypotter <liveboxandy@gmail.com>
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
This is going right in since it's long overdue. If anything is goofed,
drop me a line or just tweak it yourself if you know what's wrong. :-)
Make HW/SW codec interface more uniform when emulating HW functionality
on SWCODEC for functions such as "audiohw_set_pitch". The firmware-to-
DSP plumbing is in firmware/drivers/audiohw-swcodec.c. "sound_XXX"
APIs are all in sound.c with none in DSP code any longer.
Reduce number of settings definitions needed by each codec by providing
defaults for common ones like balance, channels and SW tone controls.
Remove need for separate SIM code and tables and add virtual codec header
for hosted targets.
Change-Id: I3f23702bca054fc9bda40f49824ce681bb7f777b
Implements double-buffered volume, balance and prescaling control in
the main PCM driver when HAVE_SW_VOLUME_CONTROL is defined ensuring
that all PCM is volume controlled and level changes are low in latency.
Supports -73 to +6 dB using a 15-bit factor so that no large-integer
math is needed.
Low-level hardware drivers do not have to implement it themselves but
parameters can be changed (currently defined in pcm-internal.h) to work
best with a particular SoC or to provide different volume ranges.
Volume and prescale calls should be made in the codec driver. It should
appear as a normal hardware interface. PCM volume calls expect .1 dB
units.
Change-Id: Idf6316a64ef4fb8abcede10707e1e6c6d01d57db
Reviewed-on: http://gerrit.rockbox.org/423
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested-by: Michael Sevakis <jethead71@rockbox.org>
As per title this patch aims at splitting common target
code and specific target code in a better way to
support future ports within the same environment
(e.g. Samsung YP-R1 where the Linux and the SoC
are the same, with differences in hardware devices
handling)
Change-Id: I67b4918c46403b184d3d8f42ab5aae7d01037fd0
Reviewed-on: http://gerrit.rockbox.org/409
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
Tested-by: Thomas Martitz <kugel@rockbox.org>
CPU frequency scaling is basically useless without scaling the
memory frequency. On the i.MX233, the EMI (external memory
interface) and DRAM blocks are responsable for the DDR settings.
This commits implements emi frequency scaling. Only some settings
are implemented and the timings values only apply to mDDR
(extracted from Sigmatel linux port) and have been checked to
work on the Fuze+ and Zen X-Fi2/3. This feature is still disabled
by default but I expected some battery life savings by boosting
higher to 454MHz and unboosting lower to 64MHz.
Note that changing the emi frequency is particularly tricky and
to avoid writing it entirely in assembly we rely on the compiler
to not use the stack except in the prolog and epilog (because
it's in dram which is disabled when doing the change) and to put
constant pools in iram which should always be true if the
compiler isn't completely dumb and since the code itself is put
in iram. If this proves to be insufficient, one can always switch
the stack to the irq stack since interrupts are disabled during
the change.
Change-Id: If6ef5357f7ff091130ca1063e48536c6028f23ba
Merge sd and mmc drivers into a single sdmmc driver. This allows
some factoring of the code and simplify bug fixing. Also fix the
dma/cache related issue by doing all transfers via a correctly
aligned buffer. The current code is not smart enough to take
advantage of large user buffers currently but at least it is safe!
Change-Id: Ib0fd16dc7d52ef7bfe99fd586e03ecf08691edcd
Logs information, errors, etc to disk using the register_storage_idle_func
mechanism to write to the disk when available. Currently, this is disabled
in normal builds, but can be enabled by adding ROCKBOX_HAS_LOGDISKF to the
config file. By default, it uses a 2KB buffer and drops text if the buffer
overflows.
The system includes a simple warning level mechanism that can be used to by
default exclude non-serious errors from logging on release builds.
Change-Id: I0a3d186a93625c7c93dae37b993a0d37e5a3a925
Reviewed-on: http://gerrit.rockbox.org/288
Reviewed-by: Jonathan Gordon <rockbox@jdgordon.info>
Tested-by: Michael Giacomelli <mgiacomelli@gmail.com>
Reviewed-by: Michael Giacomelli <mgiacomelli@gmail.com>
Basically it uses the default SI4700 radio chip driver, the only thing that's different is the I2C access,
written specifically to interact with my kernel module.
Next things to add are:
- RDS support!
Change-Id: I0ed125641e00f93124d7a34f90dd508e7f1db5a4
Signed-off-by: Lorenzo Miori <memorys60@gmail.com>
Refactor native/hosted implementation seperation while at it
(no wrappers starting with _ anymore).
Change-Id: If68ae89700443bb3be483c1cace3d6739409560a
The freescale firmware partitions has a lots of quirks that
need to be dealt with, so do it the proper way.
Change-Id: I8a5bd3fb462a4df143bc6c931057f3ffedd4b3d3
The icoll code now has an IRQ storm detection mechanism which
will prevent the device from hard freezing in case it happen.
Change-Id: I9861238dce61d29af1e48f9c534ec63a7f23465c
Simplified stack unwinder for ARM. This is port of
http://www.mcternan.me.uk/ArmStackUnwinding/
backtrace() is called from UIE() on native targets
and from panicf() on both native and ARM RaaA.
Change-Id: I8e4b3c02490dd60b30aa372fe842d193b8929ce0
Now lcd_framebuffer is the only framebuffer in the system. We still use a ARM-buffered buffer
which serve as an intermediate buffer for copying, to accomodate the requirement of the controller.
We implement lcd_update_rect() properly using this new scheme (this requires two little quirks),
this allows to implement lcd_blit_yuv with the right semantic (bypasses the framebuffer). YUV to RGB
conversion is still done in software but the DCP CSC should be able to do that but the hardware rotation
scheme is not the same as our software so it will require some tricks.
Change-Id: I0752e9c2f1a705d2e6a6010084e1f150965d8370
Core, codecs and plugins link it separately so this gets rid of SOURCES trickery.
Don't build it for hosted targets.
Change-Id: If15ef90e93cd218a4352ae8e89eea95d3122452f
move prototypes to ascodec.h
move code to ascodec*.c
YPR0: use adc-as3514.c instead of duplicating it
TODO: merge as3514.h and ascodec.h ?
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31626 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
Voltage can be read using as3543 adc (i.e. ascodec api, on this target implemented
via ioctl()). TODO: Look into possibly controlling charging more by re-using
powermgmt-ascodec.c. However, charging seems to be controlled by the kernel,
so may not be needed.
Charger state can be read using /dev/minivet. It allows to differentiate between
wall charger and usb charging, but that's not implemented (is it even worthwhile?)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31470 a1c6a512-1295-4272-9138-f99709370657
This port is a hybrid native/RaaA port. It runs on a embedded linux system,
but is the only application. It therefore can implement lots of stuff that
native targets also implement, while leveraging the underlying linux kernel.
The port is quite advanced. User interface, audio playback, plugins work
mostly fine. Missing is e.g. power mangement and USB (see SamsungYPR0 wiki page).
Included in utils/ypr0tools are scripts and programs required to generate
a patched firmware. The patched firmware has the rootfs modified to load
Rockbox. It includes a early/safe USB mode.
This port needs a new toolchain, one that includes glibc headers and libraries.
rockboxdev.sh can generate it, but e.g. codesourcey and distro packages may
also work.
Most of the initial effort is done by Lorenzo Miori and others (on ABI),
including reverse engineering and patching of the original firmware,
initial drivers, and more. Big thanks to you.
Flyspray: FS#12348
Author: Lorenzo Miori, myself
Merry christmas to ypr0 owners! :)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31415 a1c6a512-1295-4272-9138-f99709370657
The new menu is very helpful on RaaA, but also shown in the sim. It shows
the process cpu usage, process' time stats (user,sys,real) and the cpu
frequency stats.
It uses a thread to sample the data, however the thread is not created
until the menu is visited for the first time.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31364 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
Only done for files shared across multiple targets
Note that several targets share the same CONFIG_LCD but use completely
different drivers
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31285 a1c6a512-1295-4272-9138-f99709370657
add a comment about why we don't return 0 when no tuner was detected
build the file on all as3525v2 targets
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31284 a1c6a512-1295-4272-9138-f99709370657
pcf5060*.c has the same name than the RTC driver, but it's not the RTC driver itself
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31280 a1c6a512-1295-4272-9138-f99709370657
tuner and rtcs are already included by CONFIG_TUNER and CONFIG_RTC
It's not possible to remove all duplicates, because some models must support 2 RTCs.
a bitfield could be used instead, like is done for CONFIG_TUNER
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31279 a1c6a512-1295-4272-9138-f99709370657
