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
It never worked, and hasn't compiled in something like a decade, Given
the HW capabilities (limited onboard flash, no expandability) there's
really no point in trying to fix/complete it.
Change-Id: I7d175089840396f8891645bd10010d730dd5bfdc
They were never finished, never saw any release ever, and haven't
compiled for the better part of a decade. Given their HW capabilities [1],
they are not worth trying to fix.
[1] 1-2MB RAM, ~256MB onboard flash, no expandability
Change-Id: I7b2a5806d687114c22156bb0458d4a10a9734190
There's absolutely no way for gpio_config() to get called from two
different threads due to the co-operative threading model, and it
is unsafe to call from IRQ context no matter what we do.
Change-Id: I58f7d1f68c7a414610bb020e26b774cb1015a3b0
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
After continued reports of corruption using iFlash adapters, I went
digging for more clues, and this combination of changes seemed to
solve data corruption with the iFlash adapters on the ipod video:
1) Instead of SLEEP, use STANDBY_IMMEDIATE when we detect drive
as an SSD or CFA-compliant device. The latter is technically higher
power than the former, but what this means in practice is unclear.
2) Don't check ATA powermanagement flag prior to issuing powermgmt
commands. This reverts the previous "workaround" for the FC1307A --
and PM is a mandatory part of the ATA spec for any CFA device.
3) Prior to issuing SLEEP/STANDBY_IMMEDIATE, issue FLUSH CACHE. The
ATA spec says this is redundant for the latter, but says nothing
about the former. Either way it is always safe to call first.
4) Delete all other FC1307A_WORKAROUND code related to powermgmt flags.
Change-Id: I492d06664c097d9bbd5cccfb9f5b516da165b1ee
Although data transfer is reliable with DMA, it seems to cause hangs
and lockups during the early stages of connection and it's not clear
what the cause might be.
Change-Id: I9a83089c31d28309f0534dcdedf3c8c8348e6e3d
This only required a minor patch to the usb-designware driver due
to DMA requiring physical addresses -- on the X1000, these differ
from virtual addresses so we have to do the usual conversion.
Both the mass storage and HID drivers work, but there are a few
issues so this can't be considered 100% stable yet.
- Mass storage might not be detected properly on insertion,
and USB has to be replugged before it shows up
- HID driver may occasionally panic or hang the machine
Change-Id: Ia3ce7591d5928ec7cbca7953abfef01bdbd873ef
- Added register names to reduce usage of magic numbers
- Added function to control max charging current, needed for USB
- Corrected comment about axp173, since FiiO M3K has an axp192
Change-Id: I6604ce8d44e5a2ee84061cf042d17ccc4734ac57
After conducting some simplistic tests, I found that the power usage
did not appear to be affected by the CPU frequency.
I tested by playing back a 44.1 KHz FLAC file on single track repeat,
and measured current with the AXP173's battery discharge current ADC.
The button and LCD backlights were set to always on. Headphones were
unplugged and the volume was muted to eliminate any influence from
the headphone amp.
On average the current usage was between 78-81 mA at 1008 MHz, 252 MHz,
and 112 MHz. If anything, 1008 MHz drew _less_ current than the lower
frequencies, by about 1-3 mA.
A possible explanation for this, assuming it's not just a bias of the
test, is that the CPU idle state saves so much power that it's better
to maximize the real time that the CPU spends idling. More systematic
testing is needed to confirm this.
Change-Id: I527473e8c4c12bc1e94f8d4e849fecc108022abe
There's no point including this in normal builds: the stats are not
used for anything, they are not really of interest to anyone except
developers, and add a small overhead to the kernel tick.
Change-Id: I1b4f67cc62d11d634a8cec279dca513dd10eea96
Initializing the clocks in the SPL brings Rockbox in line with
how the FiiO M3K's original SPL works. It's likely other X1000
devices do this too.
There was a logic error in the previous setup: the code falsely
assumed that DDR memory would always be running from MPLL, but
it would be switched to APLL by the bootloader. Rockbox would
then try to re-init APLL, albeit with the same parameters. Maybe
this was the cause of the boot hang on some units.
Change-Id: I64064585e491bbdf1e95fe9428c91a9314f2a917
What we really want is to avoid any interrupts being generated
before the drivers which handle them are properly initialized.
Intead of trashing all GPIOs, search for the problem pins and
fix them, leaving the others alone.
This fixes the M3K's button light flickering on boot and should
stop the M3K from entering a potentially confusing "dead" state
where all the lights are off but the CPU is still on.
Change-Id: I13a6da0f0950190396bff5d6e8c343c668e8fea1
SPL is now designed so core X1000 code is in control of the boot,
under the reasonable assumption that the device boots from flash.
It should not be too hard to adapt to other X1000 ports.
The biggest functional change is that the SPL can now read/write
the flash, under the control of a host computer. The SPL relies
on the boot ROM for USB communication, so the host has to execute
the SPL multiple times following a protocol.
Change-Id: I3ffaa00e4bf191e043c9df0e2e64d15193ff42c9
'Bugfix' mono_bitmap_part reads ahead in the buffer,
if the height is <= char bit pixels other memory gets read
Change-Id: I6e0d7a9017e1f9c371ffbd56af149ac20cb82341
Tested on eros q, everything measured from line out,
open circuit.
- volume steps were approximately double the dB they
were labelled as, so "-2 dB" would result in a change
of about -4 dB from maximum (0, +6.2dBV)
- maximum volume defining the line out volume only
changed every 10 values, and then was not close
to correct- "-10 dB" resulted in -2.5 dB from maximum
This gets the volume dB approximately correct, and
maximum volume correctly sets the line out volume.
I was unable to get odd values in the max volume
to work, so set the step size to 2 instead of one.
For "consumer level" (-10dBV), set to -16.
For "Pro level" (+4dBu -> ~1.8dBV), set to -4.
Change-Id: I898b85d768153579a893b23551019af88f865d21
It was just being used as a proxy "yeah, we called hw_init()" so
just use a flag for that directly.
affects rocker, erosq, xduoo x3ii/x20, and fiiom3klinux
Change-Id: I14bd9f8d91f1d6cc8de0982a7426e2a103c6bfce
Detection at startup is proving to be unreliable. Even if card is not
present at startup, upon insertion it will sort itself out properly.
Change-Id: I9ee90b724c90c530a39264f698c200a48aa72b1d
Including direct use of the external SD card mount
Known issue: If SD card is inserted at startup, it must be
ejected and reinserted to be registered.
Change-Id: I5f420160bda32135cbb088c1e8b04b6e3a73018e
(Don't include rbpaths.h in settings.h, or string-extra.h in rbpaths.h)
Build-tested on rocker, erosq, mini2g, nano2g,
xduoox3, clipzip, dx50, and uisim
Change-Id: If32e9c9910f5c8247a655cb64522b84d6d7ccbb5
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
There is already a sound_numdecimals() function, according to Git
it's been around since 2005. No need to add another one :).
This reverts commit 92a0ab8789.
Change-Id: I533ebf1763dd7a27346842982493d4550f05ad7c
It turns out #include "settings.h" pulls in rbpaths.h which ends up
remapping open() to the path-mangling rockbox open().
By defining RB_FILESYSTEM_OS we prevent the remap. My mistake for not
testing this before committing!
Change-Id: I2978eb7b413693c4cb887b7ac7b2457780db7d25
With a full-scale 440Hz tone, the line out voltage
measured approx. 5.8Vpp at the 0 setting. WAY too hot!
(9 dBV, in fact)
For 0.894Vpp (-10 dBV - consumer devices), -18 appears to be
about right for line level signals, but for "pro" equipment
a different level may be desired.
Therefore, the user to cap the line out level by re-using the global
volume limit setting.
Change-Id: I0d1d6482ea95537e9a2d00884eaee2713771c614
Inline assembly in RoLO and the FiiO M3K bootloader used 'jr' to
jump to a newly loaded Rockbox binary, but incorrectly left the
branch delay slot open. That gives GCC an opening to place illegal
instrutions, etc, which might cause an unhandled exception.
Change-Id: Ia7a561fe530e94a41189d25f18a767c448177960
- Proper error codes are now returned from all functions. These codes will
be used by a host-side flash tool for error reporting.
- nand_erase_block() was replaced by nand_erase_bytes(). The caller can't
know how big an eraseblock is with the current API, so next best thing
is to verify the correct alignment inside the call and reject the erase
if it isn't properly aligned.
- Fixed typo in nandcmd_block_erase() which would cause an SFC error to be
interpreted as success. Yikes.
Change-Id: Id4ac9b44fa7fc2fcb81ff19ba730df78457c0383
Ensure the default setting reflects what the service manual says the
official battery capacity is. Change the ranges to reflect what
replacement batteries are actually available.
This range is actually much shorter in reality due to these units
requiring the rarer 3 pin battery type that uses a thermistor. As such
there's only one real replacement battery for each.
So the HDD1630 caps out around 700 mah while the HDD6330 caps out around
680 mah.
Change-Id: I2dbbba83ad2cd6e1d84e3481c4af84a06c45e16b
headphone ADC thread stack was slightly too small. Bump it up a bit.
(it was _perfectly_ sized for the prior older toolchain+optimization flags...)
Change-Id: I2ca67c2b85c54f879892a31e281d7696f893389c
Use of IF_COP_CORE was mistakenly introduced as part of 89acde6af2,
effectively short-circuiting multiple tests resulting in the code
paths always being executed, on both cores.
Use the correct macro, so per-CPU paths are handled properly.
Change-Id: Id346cf759fc1b06b7d56694d7af1f469caf785a4
This appears to finally fix the issue
turns out the status register we were writing was only for the CPU
COP cache flush wiped out the CPU cache
--
Added some defines to cut down on the magic numbers
Added some comments explaining such
Set the address to full 20 bit address
0x1FFFFF which is then left shifted 11 internally -- somewhere around 4GB?
Link explains the cache status bits
https://daniel.haxx.se/sansa/memory_controller.txt
Change-Id: I57b7187c2f71a5b54ce145bf3a21ed492a8993cb
Enable its use in the jz47xx MIPS targets.
(accidently committed g#3249 before making these changes)
Change-Id: I1791946f632901f0c7a94b04b009671aa0d71717
This is just a minor cleanup of Solomon Peachy's code, and using
per-filesystem buffers instead of a single static buffer.
Tested and working on the FiiO M3K.
Change-Id: I3c19e8cc24e2f8aa07668c9d1c6d63364815050a
This uses the new unicode string literal feature that is available
now to greatly simplify the initialization of these special string
types. This makes them much more readable at a quick glance.
Change-Id: Iad8b49aa763486608e3bb7e83fb8abfb48ce0a7b
-- apparenty 0x4 aligned doesn't work properly
requires 0x8 alignment at least for the h10 20gb
but enabled for all processors that define MEM_ALIGN_ATTR
Change-Id: I11edaab183b91a6d158f1f439f173b9b699dc914
-- apparenty 0x4 aligned doesn't work properly
requires 0x8 alignment at least for the h10 20gb
but enabled for all arm processors
assign the default framebuffer to the default_vp as well
Change-Id: I0b76c30f2ddb5d6d2f7c6a132e4081aee58da17b
In the old position of the call, the first battery reading would
be made before initializing the target's power management code.
If the target needs to initialize before giving a battery reading,
then the first reading would be wrong and the power thread might
inappropriately shut down based on a false zero reading.
The new position avoids forcing special-case logic onto the target
power management code.
Change-Id: I483cfabe30c6881d80a1094fd526fa0065523d19
This allows the user to make use of the DAC's power-saving abilities.
The two modes are "high performance" and "battery saver". This feature
is supported by the AK4376 DAC in the upcoming FiiO M3K port.
The setting is only a manual toggle right now, but in the future it
could be hooked up to the battery level (via another setting) so it
can be toggled automatically when the battery gets too low.
Change-Id: I482af6e2f969fcbdeb3411bd3ff91f866b12d027
The storage subsystem aggressively issues SLEEPNOW events when idle
and power off happened a fixed 2s later. This turns out to not be
enough time for FC1307A (eg iFlash) adapters to flush outstanding writes.
So, when we detect a lack of PM support, increase the poweroff delay to
5 seconds to compensate for not being able to issue the ATA SLEEP command.
Hopefully this is enough time. If not, we will have to re-disable PM
entirely when we detect these popular adapters. Thankfully that is now
just an #ifdef away.
Change-Id: I4112b9acb965973d81f70483bd9d595461c7301c
It's possible to get up to 3000mAh batteries for this device, although
it requires that you use an iFlash adapter to make enough space.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Change-Id: I0d0d02aa30caffcae4a7e8c805516a1266eef359
The FC1307A ATA->SD chipset (used by the common iFlash adapters)
doesn't support mandatory ATA power management commands, leading to
massive data corruption if they were issued.
A workaround was identified (54629073ae) that basically disabled all of
rockbox's power management code for these adapters, which extends well
beyond the specific ATA commands issued.
This patch moves the gating test to the issuance of the actual SLEEP,
so that the rest of rockbox's PM code can function as intended. This
allows the device to get powered down when idle, yielding potentially
significant improvements in battery life.
Change-Id: Ia13e2405243fe5efe6f68c3a549ab4933567790b
* PREV/NEXT now swapped so they do what is expected in most contexts
* List and setting context retains prior behavior
* Enable the ADC that reads the headset remote and map the keys.
* As ADC-based remote "events" arrive as press/release pairs,
delay the button release.
Change-Id: I22d4eac3bfe1573b50eca795cf377bdafdeb5336
affects all hiby targets, fiiom3k, and ibasso dx50/dx90
As well as deduplicating a small pile of code, this also implements
hysteresis so we're not doing a sysfs read/lookup multiple times
back-to-back every time the power management tick fires.
Change-Id: I2f7672acbb36341becf67e07960c24c681270d09
This means we will no longer send them routinely and instead rely on
the HID driver to send them when the host requests it. This also
moves the reporting out of the power management code where it probably
did not belong in the first place.
Change-Id: I9c8420e81897f1f6caaa55ffacc7525589f1ef75
Previously these were placed in DRAM, which is overwritten by RoLo
when it loads a new image, but RoLo must call commit_discard_idcache()
after loading the image.
Change-Id: I5dcc4ca711b774166f83c668695edbcabfab2604
This allows rockbox to report its battery status through the
HID Battery Strength method that is available through the
Device Controls usage page.
Change-Id: Ia7a7dd9b9d476dd9df5a5f5becabc5ae823e9a89
SSDs that respect powermgmt commands should be treated the same, as the
powermgmt commands are an important part of ensuring it's safe to shut
down.
And greatly expand the comment explaining things.
Change-Id: Ia52b99fca802f495422b5ee097390a72dbc28f61
Commit 5462907 made sure that SLEEP commands weren't issued on devices that don't support ATA power management commands (e.g. certain CF->SD converters including several iFlash models).
Since Rockbox waits for the disk to become inactive in shutdown_hw(), which won't happen in this case, the OS would previously stall during the shutdown process until a timeout was reached.
Change-Id: I03bb05f6f6401bb8f0da5d0b76bd3f07681fdc06
The filesystem API often passes in unaligned receive buffers, and some
code (eg BMP reader) processes data in-place, leading to data loss when
we dropped the cache.
(And document exactly what we're doing, so we don't go through this again
at $future_date)
Change-Id: If47a7f2148a5a1a43777f0bd3be1bdfe8239e91e
Since that encompasses _all_ of our native targets in a post-archos world,
either replace it with #if (CONFIG_PLATFORM & PLATFORM_NATIVE) or
delete it altogher as appropriate.
Change-Id: I9128a456e850d5c96a9e05806aad3acd923f90c5
In fixing the original bug I tried to optimize discard_dcache_range()
to minimize writeback and inadvertently introduced a second bug, which
typically ends in a TLB refill panic.
It occurs only if the range fits within one cache line, and when both
the start and end of the range are not aligned to a cache line. This
causes ptr to be incremented and end to be decremented, so ptr > end,
and the loop can't terminate.
Change-Id: Ibaac072f1369268d3327d534ad08ef9dcee3db65
- 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
ATA DMA was enabled for all PP502x targets in d118f47 after previously reported instabilities were thought to have been fixed. The iPod 4G target remains unstable when UDMA 2 is enabled. File system corruption will eventually occur even using stock hardware in normal usage, according to both my own experience and that of several other forum users. UDMA 1 appears to be stable.
Change-Id: I8526bad9e879f5dad5174cfe07cd8828d8b72406
Without this, if a device is left plugged in and idle, unplugging it will
trigger an immediate shutdown.
Change-Id: I65caaa0c1473562ec5d0bb776b01d4d222d69965
Basically no longer treat SCROLL_FWD/BACK as "button" events, instead
relying on the scrollwheel hooks to handle things properly.
Change-Id: I9bf18595ab3ca68e912f6dfb1f2eac2544578e73
Before this was just implemented inline wherever it was needed. Now
it is provided as 2 inline functions in a header called checksum.h.
There should be no differences in actual behavior.
Change-Id: I5d756cc01dc6225f5cc8b6af90911a3fc7b57cd5
* Bump internal mix buffer size by 4x, to 1K frames (matching ALSA period)
* Handle an underrun that occurs when filling the audio buffer
* Log underruns and make them available in the debug info
Change-Id: I28d56dd35d88851fa167ad92368a5882937a758f
It's not large enough on some targets.
(this will be revisited when the USB insertion prompt stuff is moved
out of the USB helper and over to the main thread)
Change-Id: Iefed2cdf2fbb4ce92569fc5cacbdb479b7d24e61
This removes all the pre-release bootloader of version 7 and
replaces them with production releases of version 8. The
pre-releases have their own problems and should be left
behind as they were never officially released.
Change-Id: If96531ba63cf4401d04133bda94735fe94ae4de1
This makes it so the thread cached variable is only read if building
the regular firmware. For bootloaders the data is now read directly.
This fixes the functions for bootloaders so they do not have to import
the power management code just so these functions will work when in
the bootloader.
Change-Id: Ic425b02c08b48df7a11a6c19c022b0e1cb316a85
v3: Add in config option
v4: Bugfixes
v5: Force a redraw upon exiting
v6: keypress-in-chargeonly mode enables mass storage (and vice versa)
v7: Fix bootloader builds
v8: Update manual, and have bootloader respect keypresses
v9: Change default to mass storage (ie no change in behavior)
todo:
* test-build dx50/dx90
* Switch from yes/no to proper menu?
* prevent WPS progress bar from drawing over us
Change-Id: I82e0ccb08497b7a5aa756ce77f1332ee963703a7
...
Change-Id: I7946cf240b18a4fa8ace5e25e1eb6e97b8b12d7c
This was introduced in e13c600133 back
when the author was trying to optimize the LCD code with DMA. For
whatever reason this broke the bootloader for the last 10 years or so
and no one could figure out why. This is now fixed.
However the bootloader is still currently broken in HEAD due to recent
changes to the LCD code. A fix for that is not yet known.
Change-Id: I046d53f9f391f558c391f2fadb6b260fe3be4d92
* 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
This overhauls most of the code to be easier to understand in terms
of the interactions with the flash. I found the original to be rather
confusing with how it kept switching between byte and word offsets.
My solution was to make all external access to the flash in terms of
sectors and bytes. Whatever the flash uses internally is now handled
by the subroutines for performing the erase, program, and verify
operations.
This helps make it far more consistent for the code that actually uses
these operations as they do not need to concern themselves with word
sizes and offsets anymore.
As a side effect of this change the flash operations are now done
entirely by subroutines; even the batch operations that used to use
custom loops.
Additionally some functions were merged with other functions in order
to reduce the amount of functions as well as consolidating common
code fragments.
Change-Id: I4698e920a226a3bbe8070004a14e5848abdd70ec
Some mSATA adapters seem to have trouble working with Rockbox using our
normal PIO timings; the timing value we use is probably out of spec and
is different to the OF. Switch to using the OF's timings according to
which PIO mode we select. This may not completely resolve problems with
these adapters but allows Rockbox to boot and play audio.
Change-Id: If73210700eb4af01864b373709ee1d15c775fb11
Also audiohw driver to specific device name, rewrite alsa controls code to
cache more data, thus making the code easier and use less stack. Avoid using
short/long in pcm alsa code since it's the wrong size on 64-bit (simulator
for example)
Change-Id: Ibc1ec44396e37b6cbdedbcf37300878638e5d2d3
several issues I saw that could pontentially cause problems
scroll engine doesn't take text height into account when checking bounds
NBELEMS was one whole row too large hopefully I got them right this time
Change-Id: If303da8320429c3964fc675351cb088d46303745
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
Basically we're overflowing IRAM by 48 bytes. Shrink the stack
by 48 bytes to compensate.
Fixing this properly will require careful decisions about what
(code and/or data) to eject from IRAM.
Change-Id: Ia3054280bcbd9813b9cce83f16ba4fbd15085110
I'm currently running up against the limitations of the lcd_draw functions
I want these functions to be able to be used on any size buffer not
just buffers with a stride matching the underlying device
[DONE] allow the framebuffer to be decoupled from the device framebuffer
[DONE need examples] allow for some simple blit like transformations
[DONE] remove the device framebuffer from the plugin api
[DONE}ditto remote framebuffer
[DONE] remove _viewport_get_framebuffer you can call struct *vp = lcd_set_viewport(NULL) and vp->buffer->fb_ptr
while remote lcds may compile (and work in the sim) its not been tested on targets
[FIXED] backdrops need work to be screen agnostic
[FIXED] screen statusbar is not being combined into the main viewport correctly yet
[FIXED] screen elements are displayed incorrectly after switch to void*
[FIXED] core didn't restore proper viewport on splash etc.
[NEEDS TESTING] remote lcd garbled data
[FIXED] osd lib garbled screen on bmp_part
[FIXED] grey_set_vp needs to return old viewport like lcd_set_viewport
[FIXED] Viewport update now handles viewports with differing buffers/strides by copying to the main buffer
[FIXED] splash on top of WPS leaves old framebuffer data (doesn't redraw)
[UPDATE] refined this a bit more to have clear_viewport set the clean bit and have skin_render do its own screen clear
scrolling viewports no longer trigger wps refresh
also fixed a bug where guisyncyesno was displaying and then disappearing
[ADDED!] New LCD macros that allow you to create properly size frame buffers in you desired size without wasting bytes
(LCD_ and LCD_REMOTE_)
LCD_STRIDE(w, h) same as STRIDE_MAIN
LCD_FBSTRIDE(w, h) returns target specific stride for a buffer W x H
LCD_NBELEMS(w, h) returns the number of fb_data sized elemenst needed for a buffer W x H
LCD_NATIVE_STRIDE(s) conversion between rockbox native vertical and lcd native stride (2bitH)
test_viewports.c has an example of usage
[FIXED!!] 2bit targets don't respect non-native strides
[FIXED] Few define snags
Change-Id: I0d04c3834e464eca84a5a715743a297a0cefd0af
In short, the display fading back in after a pause resuming interferes
with the audio codec, causing BadThings(tm) that cannot be recovered from
This really is just avoiding a known trigger; there's no guarantee this
condition won't occur under random circumstances during normal use,
and there's no good way to work around this from within rockbox.
I suspect the underlying problem is that both the display control and
codec control share an i2c bus, but the kernel drivers implementing them
isn't using proper linux bus access/locking.
Change-Id: Id4f56f9cb269ed74aac2f041146b3630cef09030
This also modifies the configuration file to include macros
defined in the H100 / H120 implementation.
Change-Id: Iae845889c98661ec548c04fc57e733dcc346c0f1
REMOVED FROM ALL NATIVE BOOTLOADERS:
finish removing the text scrolling
pare down printf to a minimal subset (%c %s %l %d %u and %x(%p))
remove diacritic and rtl language support
GOAL 134000
START 135305
CURRENT 133700
SUCCESS! (ASSUMING IT WORKS -- UNESTED)
Change-Id: Ic3f6ac1dc260578f581ee53458b3e5bb47d313ec
* Get rid of non-async (ie tick task) mode due to inherent brokenness
* Get rid of nonblock mode; we never write if buffers aren't sufficient
* Move driver init into pcm_open() instead of pcm_init()
* Much better underrun handling
* Better error handling in some situations
* Add in recording functionality
* Use smaller audio buffers to avoid glitching
* Don't start audio buffer with silence
* Allow device name to be overridden by target
Recording portions based on work done by Lorenzo Miori in g#633
Change-Id: I0197bdc1749c28109eb79def1e6a3e1d62d8cef3
at 1 GHZ the intermediate calculation for cycles overflows 32 bits
this makes timer fail even with sensible values
solution divide both sides by 100
Change-Id: I18a4054c2d06fb72531d5496bba562f71b03984f
* Allow output device name to be specified
* Set hw/swparams prior to actual playback start, not at init
* If told to open a new device, cleanly close down old one.
Change-Id: Ib97310ec23588136c031466ee9c22312ab0f9f5a
