This way we don't need to stub out a bunch of functionality when we
don't have any actual USB class drivers enabled.
Change-Id: Ia0ecf5be4bb41bebfcd347090959f3204a2aba59
this invokes specified class driver's notify_event method.
initial purpose is to trigger a callback from isr, like a timer event.
Change-Id: Id600e9f0d8840a12da779d5a15783edf14bd76b5
First, leave USB_FULL_INIT on for all non-bootloader builds; this is
needed for devices that don't have a USBSTACK (such as most hosted
targets and ones that provide USB<>ATA in hardware)
Then unwind another hack that is no longer needed now that USB_FULL_INIT
is not set in most bootloaders.
Change-Id: I00881ac76b2469e5cd7700bad2203c58ef1e09e7
The intent here is that when HAVE_USBSTACK is not defined, or we are
in a bootloader wthout HAVE_BOOTLOADER_USB_MODE, a device may still
some of USB subsystem initialized. For example, this may be needed
to enable USB-based charging functionality.
So, get rid of the blanket enables of USB_FULL_INIT based on target SoC,
enabling HAVE_BOOTLOADER_USB_MODE on targets that need it, and clean up
the initial mess. Most of this mess is because usb_core.c has no sense
of USB_FULL_INIT or not, and is always included when HAVE_USBSTACK is
set (even in bootloaders without BOOTLOADER_USB_MODE), but dealing with
that latter case will come later.
Change-Id: I7f805b89dded39aeea2db9038209780069e3b600
Many bootloaders broke because they have only partial USB
implementations -- HAVE_USBSTACK but without HAVE_BOOTLOADER_USB_MODE...
and a pile of exceptions.
Those exceptions need to be cleaned up properly, but for now, get the
build going again by wrapping the new ack-tracking bits with the
USB_FULL_INIT define created by the above conditions.
Change-Id: I936d4989b8c8195ee30d53808f61104a4986942a
currently, exclusive disk mode was enabled at the same time as the
usb insertion. when multiple usb configurations exist, this is not
appropriate.
manage it in the core and enable it only when necessary.
Change-Id: Iadbec05fad1d1319471233227ae0e72c12079295
add second argument to usb_acknowledge.
it can be used for more appropriate connection tracking that does not
rely on timeout in the future.
Change-Id: I8a44366b7c7a1f944524c4ba8ecd6d9673746a65
Bootloaders don't have support for queue_peek or other advanced
queue functionality, so USB-enabled bootloaders can't play these games.
Change-Id: Ib807b57b84433e7a2ad019648a6c588ab424c6cd
Original author Melissa Autumn (https://codeberg.org/oopsallnaps/rockbox-hibyos) with contributions from Marc Aarts.
Adaptation to Rockbox standards by Marc Aarts
Change-Id: I09e5af7ba0a75c648e4b9fd424badc2d3665c943
The introduction of a debounce interval for USB
status by event (see e75a3fb), often resulted in the
FiiO M3K crashing after disconnecting from USB.
Shortening the interval to 10ms appears to fix this,
or make a crash much less likely at the very least.
Change-Id: Ibf1f02779ab1704d9b1c86d39b21648a3e2c4e9d
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
iap_reset_state() and iap_getc() are now passed the logical IAP port
(0 is dock/only connector, 1 is headphone connector)
Change-Id: I97421146a8cab032b90c9b4eb55b50aa00d73312
This makes status by event debounce status changes over
a 200ms period, which is what polling was already using.
This is helpful on targets where events are excessively
noisy and generate a lot of transitions during insertion
and extraction.
Change-Id: I0eae2cca93aaa865e33c94a1318c27e91c7f7c4b
USB ask mode is basically a footgun: it can't work on native targets
and doesn't work reliably on hosted ones, and it continually produces
a slow trickle of problems. FS#13317 gives a rundown of the issues.
Removing the setting seems like the best solution for now, since a fix
would be pretty involved.
This partially reverts 60f581e8f5. The USB Mode setting is left in
place so the option can be added back later in a non-buggy way.
Change-Id: Ie01b28dd2ed95a31b509a7834d85bac8eb866098
We have this nice event library laying around probably a few more places
we could use event callbacks
Change-Id: I9180fa9d78788d161f2587110644ca3e08df6f50
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
Without this, if a device is left plugged in and idle, unplugging it will
trigger an immediate shutdown.
Change-Id: I65caaa0c1473562ec5d0bb776b01d4d222d69965
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
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
Note: I left behind lcd_bitmap in features.txt, because removing it
would require considerable work in the manual and the translations.
Change-Id: Ia8ca7761f610d9332a0d22a7d189775fb15ec88a
Cleaned up, rebased, and forward-ported from the xvortex fork.
(original credit to vsoftster@gmail.com)
Change-Id: Ibcc023a0271ea81e901450a88317708c2683236d
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
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
For some reason, the bootloader and config files didn't define
HAVE_BOOTLOADER_USB_MODE, also remove the special cases in usb.c which they
implied.
Change-Id: I68c29be7d03627e64cac4ff7678e0c211e087a8c
Either by mistake or because its meaning changed, usb_powered() doesn't mean
what the name suggest, so clarify its meaning by renaming it to usb_powered_only.
So use of usb_powered() are replaced by usb_inserted() when it makes more sense.
Change-Id: I112887e2d8560e84587bee5f55c826dde8c806d8
Reviewed-on: http://gerrit.rockbox.org/1097
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Except for unfinished or experimental ports, it isthe case that
USE_ROCKBOX_USB and HAVE_USBSTACK are both defined or both undefined.
Furthermore, it is a leftover of some early developments on the USB stack and
doesn't make sense anymore.
Change-Id: Ic87a865b6bb4c7c9a8d45d1f0bb0f2fb536b8cad
Reviewed-on: http://gerrit.rockbox.org/1091
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Letting go of the button before the host is detected allows storage mode
to be entered even though a button was down when plugging. Sometimes the
host would try several times and the button would have to be held down
for several seconds to avoid a storage connection.
The adjustment wasn't made when switching to setup request host
detection.
Change-Id: Iab3bced5bfb1478d4d9a7baab2a2a1144afaf437
Some USB controllers like the one of the Rockchip 27xx handle some
requests in pure hardware. This is especially a problem for two
of them:
- SET ADDR which is used by our core to track the DEFAULT/ADDRESS
state and is required for the drivers to work properly
- SET CONFIG which is used by our core to initialise the drivers
by calling init_connection()
In these cases we need a way to notify the core that such requests
happened.
We do this by exporting two functions which directly notify the
core about these requests and perform the necessary init steps
required without doing the actual USB transfers. Special care is
needed because these functions could be called from an interrupt
handler. For this reason we still use the usb_queue and introduce
new IDs so that they are processed in order and safely.
No functional change is intended, both in the usbstack and on
targets without such quirks.
Change-Id: Ie42feffd4584e88bf37cff018b627f333dca1140
FreeBSD apparently sends a SET_ADDRESS first, which confused our code.
This patch fixes that, and also simplifies the connection handling a bit.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31582 a1c6a512-1295-4272-9138-f99709370657
