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
