Every High-Speed capable device must be able to enumerate at Full-Speed.
The functionality at different speeds can be different. Sometimes it is
possible to support exactly the same functionality on both High-Speed
and Full-Speed, but sometimes it is not. The problem is particurarly
relevant for UAC2 because it utilizes isochronous endpoints which means
that the available bandwidth is drastically different between High-Speed
and Full-Speed.
Full-Speed isochronous endpoint can support up to 1023 bytes per frame.
Typical 48 kHz 16-bit stereo stream consumes 48 * 2 * 2 = 192 bytes per
frame. Zephyr UAC2 instances with such streams are fine to work both at
Full-Speed and High-Speed.
An example stream that is too much for Full-Speed is the sometimes used
192 kHz 24-bit stereo (whether or not it is useful is out-of-scope here,
because it should be up to application developer) which would require
192 * 3 * 2 = 1152 bytes per frame.
Because the bandwidth required for audio stream depends on three
different parameters (sample rate, bit resolution and number of
channels), the UAC2 implementation should not automatically limit
available parameters to fit bandwidth requirements.
Adding explicit full-speed and high-speed boolean options to zephyr,uac2
compatible seems to be not only the easiest solution to the problem, but
also the most flexible one. Depending on the use case, the application
developer can then decide for example:
* to not support High-Speed at all - by having one zephyr,uac2 instance
with full-speed property
* to not support Full-Speed at all - by having one zephyr,uac2 instance
with high-speed property
* to support limited number of channels at Full-Speed and all channels
at High-Speed - by having one zephyr,uac2 instance with full-speed
property and separate instance with high-speed property
* to have exactly the same functionality at both speeds - by having one
zephyr,uac2 instance with both full-speed and high-speed properties
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
This commit should deal with updating
the way USBD was handling the DMA
engine. Based on the #73803 request
DMA should be handled via the DMA
driver API class and not directly.
Signed-off-by: Ioannis Karachalios <ioannis.karachalios.px@renesas.com>
define usbphy in DT and controller DT node ref to usbphy node.
define the usbphy yaml and update ehci and ip3511 yaml for usbphy.
Signed-off-by: Mark Wang <yichang.wang@nxp.com>
The polling properties are a period in us but are named as "-rate" right
now, which would imply that that's a frequency. Rename them to
"period-us" to make that unambiguous.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Although we can get the number of configured OUT and IN endpoints and
endpoint capabilities from the DWC GHWCFGn registers, we need to
configure the number of endpoint configuration structs at build time. On
some platforms, we cannot access the hardware register at pre-init, so
we use the GHWCFGn values from the devicetree to provide endpoint
capabilities. This can be considered a workaround, and we may change the
upper layer internals to avoid it in the future.
Also, add a new vendor quirk to fill in platform-specific controller
capabilities.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add initial HID device support. Unlike the existing HID implementation,
the new implementation uses a devicetree to instantiate a HID device.
To the user, the HID device appears as a normal Zephyr RTOS device.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
1. Configure 'core-clock' to 192MHz to generate necessary 48MHz
2. Support workaround to disallowing ISO IN/OUT EPs to be assigned
the same EP numbers
Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
Utilize a code spell-checking tool to scan for and correct spelling errors
in all files within the dts/bindings/timer, usb-c, usb and watchdog.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
USB Audio Class 2 (UAC2) includes a method to describe audio device
topology to host using a set of class specific descriptors. The audio
device description includes complete sample clock topology and audio
processing organization.
Zephyr specific bindings are supposed to allow user to create reasonably
simple audio device description using devicetree syntax. The bindings
currently include only the absolute minimum set required for headset
example. Bindings for other entities (Clock Selector, Clock Multiplier,
Mixer Unit, Selector Unit, Feature Unit, Sample Rate Converter,
variuos Effect Units, various Processing Units, Extension Unit) can be
added later together with the actual USB class implementation.
The main idea is that user does create one zephyr,uac2 compatible node
for every USB Audio 2 class instance. Note that in majority of cases
just one USB Audio 2 class is necessary because the number of streaming
interfaces is virtually unlimited (USB Audio 2 class can have up to 255
entities). The zephyr,uac2 node includes child nodes with compatibles
set to desired entity or audiostreaming interface. The parent-child
relationship is necessary to allow grouping entities to correct audio
class instance.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
NXP USB bindings were combined into one binding and using
a property corresponding to HAL enums which is improper use
of devicetree.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
This adds support for the USB interface for the
Renesas Smartbond DA1469x device family.
Co-authored-by: Jerzy Kasenberg <jerzy.kasenberg@codecoup.pl>
Signed-off-by: Niek Ilmer <niek.ilmer.aj@renesas.com>
Add a USB device controller driver skeleton to use as a starting point
for implementing a specific driver.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Although snps,designware-usb bindings already exist, this one is
prolematic. Compatible is too general and does not reflect
the actual controller IP. It has Zephyr-specific properties,
but has no zephyr prefix. It forces properties that are not
necessary for this controller. We start here with new bare minimum
properties for DesignWare OTG USB 2.0 controller.
The STM32F4 SoC family USB controllers, which are also implement
DesignWare OTG USB 2.0 IP, can also be used with existing drivers,
but require certain quirks. To use these we need special compatible.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Fix all comments-indentation errors detected by yamllint:
yamllint -f parsable -c .yamllint $( find -regex '.*\.y[a]*ml' ) | \
grep '(comments-indentation)'
This checks that the comment is aligned with the content.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add support for virtual USB host controller intended for use
together with virtual bus and virtual device controllers.
This driver is not an emulation of any real host controller.
The driver has initial support for handling control and bulk
transfers.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add support for virtual USB device controller intended for use
by virtual bus and virtual UHC controllers. This driver is not
an emulation of any real host controller.
The driver has initial support for handling control and bulk
transfers.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add common layer of UHC API and MAX3421E host controller driver.
This implements the bare minimum necessary to communicate with
one peripheral device.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
DTS property attributes are (by default) not required.
Explicitly specifying `required: false` is redundant.
Perhaps a warning to that effect would be useful.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The property is similar to the usb_controller_index_t
enum that is available in the NXP SDK.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
All in tree device drivers on a bus use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
Follow up on commit 37bf7cb
("dts/bindings: stm32: Set pinctrl-[0/names] properties as required")
Report lack of those fields soon at build to avoid cryptic
DT api build error messages.
Signed-off-by: Maciej Zagrabski <maciej.zagrabski@grinn-global.com>
This add support to pinctrl at Atmel sam0 usb dc driver. It updates
all boards with new pinctrl groups format and drop pinmux entries.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
This update Atmel sam usb drivers to use pinctrl driver and API. It
updates all boards with new pinctrl groups format.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Use the new pinctrl API to configure pins.
Additionally, rename usb_pinctrl to usb_pcfg to better fit
new pinctrl API.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Add hidden Kconfig option to Kconfig.cdc and allow
to configure CDC ACM UART device from devicetree.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Current USB device controller drivers (drivers/usb/device)
do not use DEVICE_DT_GET but the properties from devicetree,
and USB device controller node is parent for CDC ACM UART and
AUDIO children nodes.
Add USB device controller binding and node to keep the samples
building for native_posix driver.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Clean up multi-line strings so they will show up properly in the
bindings index in the HTML documentation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The value of a label property isn't really the name of an API. It's
the name of a device, as passed to device_get_binding().
Let's just say that directly so people know what this means in
practice instead of what's currently used as the description, which is
harder to understand and not really accurate.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
By this commit USB audio class implementation is introduced
to Zephyr.
The Zephyr USB audio device class follows bellow
documentations:
- Universal Serial Bus specification rev2.0 (usb20.pdf)
- Universal Serial Bus Device Class Definition for Audio Devices
(audio10.pdf)
- Universal Serial Bus Device Class Definition for Audio Data Formats
(frmts10.pdf)
- Universal Serial Bus Device Class Definition for Terminal Types
(termt10.pdf)
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
Add any useful information from 'title:' to the 'description:' strings
(e.g. explanations of acronyms), and remove 'title:' as well as any
copy-pasted "this binding gives a ..." boilerplate.
Also clean some description strings up a bit.
Some other things could probably be cleaned up (replacing 'GPIO node'
with 'GPIO controller' on controllers for consistency, for example), but
I kept things close to the original to avoid accidentally messing up.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
With https://github.com/zephyrproject-rtos/zephyr/pull/20185, multi-line
descriptions will be formatted nicely, but using '>' breaks it, because
it removes internal newlines (including between paragraphs).
See https://yaml-multiline.info/.
Replace 'description: >' with 'description: |' to encourage '|'. That'll
prevent '>' from getting copied around and messing up long descriptions.
This will lead to some extra newlines in the output, but it's fine.
Line-wrapping messes up any manual formatting.
The replacement was done with
$ git ls-files 'dts/bindings/*.yaml' | \
xargs sed -i 's/description:\s*>/description: |/'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
