Needed due to us commandeering the AUDIO DSP "channel" for USBAudio.
If/When we add another DSP channel, this can be reverted.
Works, but still goes to a "blank" WPS screen for a split second before
cancelling out.
Change-Id: I5fb8a1e226b4d3e46c86c59d593d807f49d7a35f
Does not seem to affect UI usability, but allowable DSP loads will vary
based on device and playback sample rate.
To-Do (someday):
- Add dedicated DSP channel
- How to apply DSP settings to above new channel? (UI)
- How to lock out timestretch from being enabled?
Change-Id: Ia24d1055340354e2c32e6008e7e2b03a8e88867d
Add feedback not based on samples used, but on buffers filled - idea
being we can do "PID" (someone who has actually implemented Real PID
could probably rewrite the calculation) based on how many buffers
we have filled versus the ideal buffer filled level (16).
Feedback is based on a historical average of the last two feedback
intervals.
This feedback math is done as fixed-point math to keep floats out of core. Note that a couple division operations needed to be strategically staged to avoid overflow or truncation.
Floats are still used for debug screen printout.
Also fixed a typo in the definition of usb_audio_control_request()
Host:
Linux: works
MacOS: works
Windows: Feedback does not work! It appears that Windows may not
support asynchronous devices at all. Playback may "work",
but results will vary as the number of buffers filled will
drift over time.
Change-Id: I027feb16705e6e46c1144b1d08920b53de42cb26
Original commit credit to Amaury Pouly, Moshe Piekarski
Pushed across the finish line by Dana Conrad
To enable, see setting under General Settings --> System --> USB-DAC.
On devices with few endpoints, this may not work while HID and/or
mass storage is enabled.
Adds new dedicated mixer channel.
setting usb-dac can have values:
- never (0)
- always (1)
- while_charge_only (2)
- while_mass_storage (3)
Relevant devices are DWC2 and ARC usb controller devices. That being:
x1000 Native targets (m3k, erosqnative, q1, others...?),
sansac200, creativezenxfi2, vibe500, ipodmini2g,
ipod4g, creativezenxfi, creativezenxfi3, sansaview, ipodcolor,
creativezenxfistyle, samsungypz5, sansafuzeplus, iriverh10_5gb,
tatungtpj1022, gigabeats, faketarget, samsungyh820, gogearhdd1630, samsungyh925, ipodmini1g, ipodvideo, creativezenmozaic, sonynwze370, creativezen, gogearsa9200, gogearhdd6330, sonynwze360, sansae200, mrobe100, iriverh10, creativezenv, ipodnano1g, samsungyh920
USB Driver-wise, it should be noted that this patch requires some
slight changes:
- proper blocking on control OUT transfers, to make sure the data is
received *before* using it, the usb_core should probably use that too
- drivers can now support interface alternate settings
- drivers can be notified of completion by a new fast handler, which
is called directly from the driver; this is is necessary for
isochronous transfers because going through the usb queue is way too
slow
Designware changes:
- enable for USBOTG_DESIGNWARE
- set maxpacketsize to 1023 for ISO endpoints
Change-Id: I570871884a4e4820b4312b203b07701f06ecacc6
Leading spaces in particular were resulting in Linux warnings/panics, but
to be safe strip out all spaces, including those in the middle.
This was noticed on an ipod6g with the stock hard drive; it reported
a serial number of ' xxxxxxxx', which is technically legal
per ATA specs, but needs to be properly trimmed.
Change-Id: I34309fe64b341caefd5b18f6d0cf539cb97d4a38
There are numerous sub-commands, this makes it possible to call the others.
Also in this patch is the ability for the "default" ATA driver to
query smart data too
Change-Id: Ie3aaf9e0b2d7a5d25d09dea34e4f10ee29047e1b
This is an unofficial command that many USB<->ATA chipsets support,
allowing direct passthrough of ATA commands to the device.
We don't pass things through as-is; instead we only intercept and handle
requests for IDENFITY INFO and SMART. Everything else will return an
error.
Change-Id: I3bbb76990e5f6f0512f6eb42825fa505475b2ecd
* Support varying-sized logical sectors in a single build, instead
of a hardcoded SECTOR_SIZE.
* Properly truncate READ CAPACITY(10) if drive has over 2^32 sectors
And fix potential alignment issues
* Properly truncate READ_FORMAT_CAPACITY if drive has over 2^32 sectors
* Support READ CAPACITY(16)
Change-Id: I744b8629131f9ede31e1a972a6700b2244f2e798
* Create new 'sector_t' type alias:
* uint64_t for all targets with HAVE_LBA48 or HAVE_SDUC
* unsigned long for the everything else
* Alter all storage APIs to use sector_t instead of 'unsigned long'
* Alter Volume/Partition/storage info structures to use sector_t
* Disk cache converted to sector_t
* ATA Core:
* convert to using sector_t for sector addresses and drive sizes
* Always fill out upper 16 bits of LBA48 addresses
* IDENTIFY INFO is fixed at 512 bytes, not SECTOR_SIZE
* USB mass storage:
* convert to using sector_t for sector addesses and drive sizes
* Implement READ_16/WRITE_16 for LBA48 addresses
* Convert FAT code to use sector_t for all sector references
* output_dyn_value() now accepts int64_t instead of 'int'
* Corrected "rockbox info" to work for (MULTIVOLUME & !MULTIDRIVE)
* Better reporting of disk and (logical+physical) sector sizes in debug info
* Detect SDUC cards and report on storage debug_info screen
To-do: SDUC
* Refactor SD core to remove duplicate code in every driver
* Card probe and init state machine
* Implement core SDUC support
* SD2.0 needs to be 2.0+ (fixed for jz47xx and x1000)
* Host and Card ID (ACMD41)
* 32-bit addressing for all read/write/erase operations (CMD22)
* ADD SDUC to target device drivers, defining HAVE_SDUC as appropriate
Change-Id: Ib0138781a0081664d11511037685503df1b93608
On PortalPlayer iPods, it looks like the serial number is available in a
specific memory location. When adding support for Samsung S5L87xx-based
iPods, this algorithm has not been limited to PP-only, so it sets the
serial number USB descriptor to random memory data.
With this change, it will use the ATA HDD serial number on iPod 6G. On
Nano 2G it won't provide a serial number at all.
Change-Id: I53d48915d629dbd87b2dbbcba5f228ca5949fa9b
Apparently a response is coming out of nowhere and tripping this
check. I can't be bothered to look into it; it would be better to
just update the ARC USB driver to the new control request API...
Change-Id: Ic5062443e060534f170d3afe17c00d3c25d1d3bd
It seems connecting an iPod Video to a Mac triggers the null
request check, resulting in a panic. Ignoring the error with
a bare return "fixes" it and allows the iPod to connect. This
isn't ideal though, because it could silently introduce bugs
on other targets.
The likely cause of this is the host sending control requests
too fast, or a driver problem (the Video uses the ARC driver,
which is still on the legacy interface), with multiple requests
getting queued at once. Since the USB core expects to deal with
only one request at a time, the second response trips the check.
Try to handle this situation a bit more gracefully by detecting
overlapped requests and returning a STALL to the host when it
occurs. At this point the USB stack is able to safely handle a
new request.
Link: https://forums.rockbox.org/index.php/topic,54414.0.html
Change-Id: I9a2b7e35620ff540ebdb39f81671377062a4917d
allow buflib_free to check for invalid or already freed handles
within the function -- remove all the invalid handle guards thru core_free
Change-Id: Ibdcbc82760fc93b674c42283fca420d94907df8e
There are various allocations that can't be moved or shrunk.
Provide a global callback struct for this use case instead of
making each caller declare its own dummy struct.
Also fixed ROLO and x1000 installer code which incorrectly
used movable allocations.
Change-Id: I00088396b9826e02e69a4a33477fe1a7816374f1
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
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
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
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
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
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
The funny thing is that the memset() for the field in question was
redundant, as the overall inquiry structure was memset(0) already.
Change-Id: I8bec0c93c9317823ff39cf7133535e3bf58fb987
Atmel AT88SC6416C CryptoMemory is almost I2C compatible. The device
is connected to bitbanged I2C bus shared with compliant I2C devices.
Change-Id: Iec54702db1bdfb93c01291eef18ec60391c63b16
On devices that can assign interrupt IN, bulk IN and bulk OUT endpoints
this change results in the serial interface working out of the box on
Linux and Windows. On Linux it is registered as ttyACM device and on
Windows it is assigned a COM port number.
On devices that cannot assign the interrupt IN this change won't have
any effect.
Implement minimum required interface control requests. Respond with
whatever line coding was set to make terminal programs happy.
Change-Id: Id7d3899d8546e45d7cb4ecc3fe464908cb59e810
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
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
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
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
For s5l8701, s5l8702 and as3525v2 targets.
The crash occurs when USB is inserted or extracted while the playlist
is being loaded or updated (it could take a few seconds for huge
playlists), at this point all buflib memory is allocated and not freed
before usb_starage_init_connection() is executed.
This workaround mitigates this panic by using static memory for USB
buffers, so this memory cannot be used for other tasks, in addition
the problem still persist when playlist load is 'paused' by USB
insertion and then updated after USB extraction.
Change-Id: Iff1db5a949361fd543e0b494924d1f2906c84b5e
Many includes of fat.h are pointless. Some includes are just for
SECTOR_SIZE. Add a file 'firmware/include/fs_defines.h' for that
and to define tuneable values that were scattered amongst various
headers.
Remove some local definitions of SECTOR_SIZE since they have to be
in agreement with the rest of the fs code anyway.
(We'll see what's in fact pointless in a moment ;)
Change-Id: I9ba183bf58bd87f5c45eba7bd675c7e2c1c18ed5
Based on g#844 and g#949, it is intended as a replacement for the
current s3c6400x USB driver.
The DesignWare USB OTG core is integrated into many SoC's, however
HW core version and capabilities (mainly DMA mode, Tx FIFO mode,
FIFO size and number of available IN/OUT endpoins) may differ:
CPU targets HW ver DMA NPTX FIFO FIFO sz #IN/OUT
-------- ------------- ------ --- --------- ------- -------
as3525v2 sansaclipplus 2.60a Yes Dedicated 0x535 4/4
sansaclipv2
sansaclipzip
sansafuzev2
s5l8701 ipodnano2g 2.20a Yes Shared 0x500 4/5
s5l8702 ipod6g 2.60a Yes Dedicated 0x820 7/7
ipodnano3g
s5l8720 ipodnano4g ? ? ? ? ?
Functionality supported by this driver:
- Device mode, compatible with USB 1.1/2.0 hosts.
- Shared FIFO (USB_DW_SHARED_FIFO) or dedicated FIFOs.
- No DMA (USB_DW_ARCH_SLAVE) or internal DMA mode.
- Concurrent transfers: control, bulk (usb_storage, usb_serial) and
interrupt (usb_hid).
Actually this driver is not used by any CPU, it will be enabled for
each individual CPU/target in next patches.
Change-Id: I74a1e836d18927a31f6977d71115fb442477dd5f
