This problem actually had nothing to do with USB boot; it's
because the cable is plugged in when the USB mode menu item
is selected. The USB thread detected the select button press
and went into charge-only mode (as it usually does when you
hold down a key in Rockbox). This is fixed by having the USB
thread ignore most keys in the bootloader.
USB connect events are delivered via the button queue, and
there were also cases where the connection could be missed
if the event happened within another UI screen. This should
also be fixed.
Change-Id: I077d705a6ac845c8713219eee45d26aa6addfa61
Guard against division by zero and prevent the time_now
value from going negative if the counter drops below zero.
Change-Id: Ia8cadfe76086d6d0200964c1f27bab0be708b135
This method, while far from perfect, is able to make use of
real-time battery usage information and updates frequently
in fine-grained increments. This should make time estimates
a lot more useful than they previously were.
Change-Id: I66c6daba88210f60a27e239fbbcc56869be3b878
The way this was done before was wrong - limiting the charge
current is not enough since the device will draw additional
power to run. Use the AXP192's vbus current limit control to
stay compliant with the USB specification.
Change-Id: I91b84e3480a432e49bec53cf2a17e4e3444404a4
I noticed a few mistakes in the old driver code and it was in
need of an overhaul anyway... I decided to scale things back,
simplify the code and remove most of the debug menus, netting
a nice code size savings.
One new feature is an advanced debug menu which is accessible
by recompiling the code with AXP_EXTRA_DEBUG. It adds quite a
bit of code size and isn't useful other than for development
so it must be manually enabled by editing the source.
Change-Id: I30e17c1194c14823decd726a574ed14451d4cb2d
This reverts commit 6ff1a935b9.
Reason: it created a mismatch between the displayed voltage
and percent since the voltage was unfiltered but percentage
was based off the filtered voltage.
Change-Id: I4cba099f2e1edf0ef7c4e17a32f566aa66f5b933
This allows battery run time to be calculated from the
actual battery usage on the FiiO M3K and Shanling Q1.
This isn't very good for the time being and the estimate
tends to go all over the place due to small variations
in current or voltage.
The Eros Q can support this feature as well, but since
it already has fixed estimates defined and the quality
of the "real time" estimate is low I am not enabling it
there.
Change-Id: Id34a93ee4b7d66f9f7e56ef0f5149f67e8e72039
I've tried to clean up cruft and clarify what's being
done, prior to adding new features. The behavior should
be unchanged.
Change-Id: If8a68b7b48173d283df981a21cdd854b714e7695
Also keeps display from lighting up before shutdown,
which reduces distractions, especially at night and
when the sleep timer is used by allowing the
screen to remain dark.
Change-Id: I1c2d1966f6fb9766532adf01e8828876a871857f
Create a new battery_current() function to report the
the battery's charging/discharging current. Move the
old runcurrent() implementation into it and clean up
some of the related defines.
Change-Id: I7dbe5b6532d291fa72add1cb23b30e3cbac8c3ca
Remove battery_read_info() which is a simple wrapper
function only used by debug screens. Use the polling
functions directly to save a bit of code size.
Change-Id: I2919f78105bab186f6933dc1823f9fa67fe74f3e
- Don't include the 'battery capacity' setting unless the
target allows changing it.
- Clean up the preprocessor conditionals used to check for
variable battery capacity support.
- Don't use a variable for battery capacity unless it is
actually needed.
Change-Id: I3d8a338f107014f2c5098bc0a44ef0cfb4df9356
Give iBasso DX50/DX90 empty adc-target.h headers like all
the other hosted targets to avoid special cases.
Change-Id: Iaae15642fdec4ff18bc9ac01245753135128f676
Rewrite the loop to update the framebuffer by rows rather
than by columns. This should (a) be more efficient on the
majority of targets using horizontal stride framebuffers,
(b) skimp a bit on code size and (c) avoid AddressSanitizer
errors caused by reading past the end of the source buffer.
Change-Id: I238d191d63bfdecd25336fd8879a63d9d6ab7087
Future-proofing against newer versions of GCC/binutils which
are stricter about the use of 'inline' functions in headers.
Change-Id: Id620812ed340f0d790ba6c5b8b5cb1d700acfbbf
This handles the case where the host sends a new setup packet
in the middle of an ongoing control transfer.
Change-Id: I1d2e02467e9b813c9827cc0699cb87a500515e31
The FT6x06 driver used for the Shanling Q1's touchscreen
has been extended to report more than one touch point. It
can also return the gesture detected by the controller,
but this doesn't seem to report anything useful on the Q1.
Multi-touch is only useful in 3x3 grid mode since the Rockbox
button API cannot report more than one touch point.
The FiiO M3K uses the same driver so it's been updated to the
multi-touch API, but functionality is unchanged.
Change-Id: I4de42f44808d6eb902e3da212d8f936b7a5042c7
Touch devices have physical buttons too, and these should be
subject to repeat acceleration. That feature was disabled for
the sake of better touch event responsiveness (apparently).
So, re-enable the acceleration feature & add a special case
to exempt BUTTON_TOUCHSCREEN from acceleration.
Change-Id: I9e097e27457fbd6b824f098e8b325ff35c59dde4
Based on a patch by Amaury Pouly which was based on a patch from Ryan
Hitchman.
I mainly moved the code for polling into the tuner driver so it can be
reused by other targets. I added the CONFIG parameter for the polling
frequency (in ticks) to save energy. Also, I did some minor cleanups.
Change-Id: I95a62e7e1e42c62dbf47ecb27a3b312a42be62aa
All three X1000 native targets turned out to have a very
similar boot configuration and used a nearly identical
makefile. Eliminate this duplication by moving the logic
into the main makefile.
Change-Id: I13044b9675c0abd605b8accdb2fee4f54549b020
Due to how the old control request API worked, the request
pointer (and the pointed-to contents) passed by the driver
must remain valid for the lifetime of the request.
The buffered copy wasn't used consistently anyway, so it
should be safe to just get rid of it.
(This only affects the old API compatibility layer.)
Change-Id: I00294c718a7515a91b84f7c7cae5220c73aa5960
In the old API, usb_core_transfer_complete() would ignore
any completions on EP0. The legacy control API will also
ignore most completions on EP0, but it only did so after
filling in the completion event.
If the driver submits a spurious completion on EP0, then
this could clobber a previously queued completion event.
Fix this by deciding whether to ignore the completion
*before* modifying the event data.
Change-Id: I68526898a96efa594ada4e94bb6851aaaf12e92a
Appears to return 0 until the axp has (presumably) completed
its first real measurement.
Note about erosq: keep the power_inint() delay large to ensure
nothing breaks in the bootloader for the time being.
Change-Id: I444e858207cc401c42f1e6ceacf067ad543d4ff8
The address from the packet needs to be saved before sending
the response -- after the response the request being pointed
to could get overwritten. This used to be done correctly but
I unintentionally broke it when updating the handler to the
new control request API.
Change-Id: I9b11548baf20dce44a82301731405dc8e8f1cef3
Ive seen no ill effects having this disabled on target so
limit it to the sim to stop Address Sanitizer from dumping
on the extra byte read. the bad data is never used AFAICT
since the loop ends
Change-Id: I8cb54e9d1f8fe28747867d861a015edb3dbfa5ff
Because usb_core_legacy_control_request() is called by an
interrupt handler the global variables used to track the
current control request at the very least need to be volatile.
It might also be necessary to disable IRQs but I'm not sure
of that.
Change-Id: I0f0bb86d0ad63734e8d3c73cb1c52fedf5a98120
We have this nice event library laying around probably a few more places
we could use event callbacks
Change-Id: I9180fa9d78788d161f2587110644ca3e08df6f50
OST timer fix (7a5130a277) causes a boot failure on some units,
the battery voltage reading needs more time to stabilize.
Change-Id: Ic4a9ba90a16fab8ac6d27dbbe7af381f7c810f8f
The battery stabilization delay call seems to need to be
about 170 at minimum now, let's do 190 for safety (+20ms).
Change-Id: Ifd0248891abe827dfcc3e6baf48cc5bef0d0cc1c
It turns out the prescaler fields in OST_CTRL are 2 bits wide,
not 3. The programming manual (as usual) is ambiguous and its
diagram shows 2-bit wide fields, but the bit positions in the
text give a 3-bit wide field. Ingenic's Linux code and my own
testing shows that they are, in fact, 2 bits wide.
This caused the OST2 divisor to be 16 instead of 4; the OST1
divisor was correct. This means that all udelay/mdelay calls
took 4x longer than they should've. After this change the OST2
prescaler will be 4, as intended, and udelay/mdelay calls will
wait for the intended duration.
Change-Id: I2ac0a9190f49b59a840c649bf586131f5f9fde82
This boosts USB transfer performance a bit, ~10% for reads and
~25% for writes, for large-ish file transfers. Rockbox is still
around 33-50% slower than the OF.
Change-Id: I236a1e5c69a290c47ed27b70cb2631111fc157ed
When performing an OUT transfer which is not a multiple of the
max packet size, the last packet of the OUT transfer should be
a short packet. However, there's no guarantee the host sends
the expected amount of data in the final packet.
The DWC2 USB controller handles this case by accepting any size
packet and copying it out to memory. So if the packet is bigger
than expected, it'll overrun the caller's buffer and Bad Things
will happen.
The USB 2.0 spec seems to endorse this behavior. Section 8.5.1
says "an ACK handshake indicates the endpoint has space for a
wMaxPacketSize data payload." So it is possible that other USB
controllers share the DWC2's behavior.
The simplest solution is to force all USB RX buffers to be big
enough to hold the transfer size, rounded up to a multiple of
the max packet size. For example, a transfer of 700 bytes would
require a 1024-byte buffer if the MPS = 512 bytes.
Change-Id: Ibb84d2b2d53aec8800a3a7c2449f7a17480acbcf
All existing USB drivers now define USB_LEGACY_CONTROL_API to
enable the emulation layer.
Control request handlers will be ported in follow-up commits.
Change-Id: I4be1ce7c372f2f6fee5978a4858c841b72e77405
This makes it possible for macros of conditionally included string
descriptors to get a correct index no matter what other usb drivers
are enabled or disabled due to the nature behavior of enums.
Change-Id: I8ccebbd316605bed0f5d90b6b73fab4a333c02fa
Write -1 to AIC_DR to initialize the "last sample"
to -1 in order to prevent power-on clicks.
It appears necessary to completely fill the FIFO,
otherwise I was able to get a click out of it, however
uncommon it was.
Not only does this prevent a click when first
playing a song after power-on, but it also seems to prevent
any click at all when powering on - previously, a small
click may have been heard when first booting.
Change-Id: I2b81c2fa6af9809ef1c354d7a08ca8f9893a7690
Previously it used the last sample, which turns out to be broken.
The AIC appears to send out a random non-zero sample continously
after boot -- probably because the last sample is uninitialized by
the hardware. Disabling playback is supposed to make it send zero
samples irregardless of the LSMP bit according to the docs, but it
doesn't seem to work this way.
- Change eliminates the white noise heard on the M3K after boot.
- Change has no adverse effects on the Q1.
- Leave Eros Q on the old setting since sending zeros exacerbates
clicking due to DAC's automute feature.
Change-Id: I9996793fc34f4475b19700d076b11505353b3836
According to a forum user, there's an audible click when changing
the volume between -32 and -32.5 dB with some headphones. Fix this
by not (ab)using the DAC digital mixer for volume control.
The mixer only provides an extra -6 dB of hardware volume range,
so the only side effect is that software volume will now kick in
at -32 dB instead of -38 dB.
Change-Id: If24d9bc0058eff3c1a29aefb155a2e378522623c
there is a 1MB free region that is used to load the firmware but we
shouldn't need that till after a USB connection
so here is my 2nd try
Change-Id: I2552db3a7fba019d7e7188984432f758ddafe548
Upon getting a USB reset, the USB core will update charging
current by calling usb_charging_maxcurrent_change(). On all
current X1000 targets this may cause a hang, since changing
the charge current involves a blocking I2C transaction.
Eg. if the host issues a reset when we're already configured
as part of error recovery, the change from 500 mA -> 100 mA
will cause a hang.
Change-Id: I5b45272c01fa16b179ae3d16bbc50c7fab9a416b
0.) B 0 /rockbox/apps/main.c:405
1.) B 1 /rockbox/firmware/kernel/thread.c thread[dircache]:1508
2.) B 2 /rockbox/apps/tagcache.c:4772
3.) U 3 /rockbox/apps/tagcache.c:4793
add logic to show count after log rolls over
clean-up
Change-Id: Ibda0a56e5d8d89aa8b7649f4f9fa64eb1ff0e08f
Adjust the battery scale to be a little better. I've set
the 100% (discharge) point to be where the battery sags to
when it is done charging but still plugged in.
Not quite sure how best to set the charge scale, it's just
equal to the discharge scale for now.
Change-Id: I9a2730c0b2051300af9eeddb4f67164f38a29002
IMHO the current name is somewhat misleading:
- usb_drv_send() is blocking and we have usb_drv_send_nonblocking()
for the non-blocking case. This inconsistent naming can only
promote confusion. (And what would we call a blocking receive?)
- Other hardware abstraction APIs in Rockbox are usually blocking:
storage, LCD, backlight, audio... in other words, blocking is the
default expected behavior, with non-blocking calls being a rarity.
Change-Id: I05b41088d09eab582697674f4f06fdca0c8950af
A reasonable default assumption for a user
would be that they can plug their device into
a USB AC adapter and it will charge with as much
current as it reasonably can. With the previous
default, an AC adapter will only do 100mA, basically
a trickle charge.
Make this configurable default per-device, so as not
to break old devices without testing.
Define TARGET_USB_CHARGING_DEFAULT to USB_CHARGING_FORCE
to use the new default.
Tested on both erosQ Native and M3K.
Change-Id: I77265d356a41d67357ebc6e9f7e0c25a37b74931
Fixes backlight not turning on after booting (tested on an iPod Mini 2G).
backlight_hw_init() copied from iPod 4G.
Change-Id: I9c32ca5ecd3dc74ea997e6cb843da79d303b0615
Set the maximum volume on both hosted and native ports
to -2 dB.
Verified behavior here on native and by borkitall on irc
for hosted.
Change-Id: I3aebc2bb4b9294a4137a33694c83139c0d76099a
'Bugfix' mono_bitmap_part reads ahead in the buffer,
if the height is <= char bit pixels other memory gets read
found with [Address Sanitizer]
also g#3332 since this is clearly a problem across the code
instead place the check for height < 8 in the lcd_mono_bitmap_part function
second try places the check above the negative y offset
this was causing glitches on the Q1 and likely other TS targets
since a negative y was added to height it made it < CHAR_BIT setting
stride = 0 even though the bitmap was >= CHAR_BIT high
Change-Id: I13bb8ab472c2ae61302a6de5d9e2c78243354460
It's not yet working and because all storage is removable (and the OF
works fine) it's of limited utility aynway.
Change-Id: I8a6a59ac16503d0f4574c3934f473cac54e86858
It has only a couple GB of onboard flash storage with no storage
driver in Rockbox. It hasn't seen any meaningful development since
its initial commit, it's not on the build farm, and the bootloader
build is broken by other refactoring.
Change-Id: Idd9e3c46fac9b96f416ce444182f97a50770e747
I feel this is probably unlikely to be called with a NULL pointer
for cachep but being that we are already doing the check why not
guard file_cache_reset as well
Change-Id: I1a13767ef28a4129ae3513f7aa999fb6c1d6fad8
Similar to the native port, the hosted port benefits from
adding a -1 dc bias to the PCM data. This prevents almost
all clicking artifacts.
Change-Id: Ic6378716774b6d88df23c476e2ef54d49f33dc72
An oversight on my part meant that setting channel balance to
100% L or 100% R would mute both channels - this logic will
prevent that.
Change-Id: I912c2745784fbbbd7a773e1234179801f2ca4680
