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
* Enabled MULTIDRIVE and ROOTFS_HOTPLUG for full hotswap!
(Requires updated bootloader/integration!)
Change-Id: I7dad1f8d375e087c36fce37bec3e9184602ede50
* Cannot turn off the LCD directly (have to rely on backlight)
* Only insmod/rmmod the usb gadget modules if state changes
Change-Id: I9ea90177d496cd035ada93e04a93a7c6f2e84706
Whether or not this is correct depends on how the source material was
mastered, digitized, and/or encoded. There is no setting appropriate
for everything.
Eventually I'd like to make this configurable, but I'd want to have it
shared with more than one target first.
Change-Id: I20a0eff4b3dc2517c33db49d4f72e85bf81d1ca6
* Specify exported USB VID/PID in target config header
* Don't fail if the sd filesystem has already been remounted
(ie due to platform hotplug)
Change-Id: Ifd2dae0c4f15086bf2bf89eb093018b3c4d2b75d
The right thing here probably to just not bother at all, as this
bootloader can't launch rockbox yet anyway.
Change-Id: I62bd22353b6adc9dbe35b94f3b60a6a67348356a
(we were trying to foward-declare functions from within static
initializer context. GCC no longer accepts this)
Change-Id: I58f316ecc84c8ab45fffc054955727a55714b0a3
