- 27 Jul, 2023 14 commits
-
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230726113816.888-13-frank.li@vivo.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20230726113816.888-10-frank.li@vivo.comSigned-off-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
platform_get_irq() directly prints error information. Signed-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20230726113816.888-3-frank.li@vivo.comSigned-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Replace tab with space. Signed-off-by:
-
Haotien Hsu authored
If memory accesses by the Tegra XUSB controller are translated through the SMMU (System MMU), the hardware may continue accessing memory even after the SMMU translations have been disabled during the shutdown process and this can in turn cause unpredictable crashes. Fix this by adding a shutdown implementation that ensures the hardware is turned off during system reboot or shutdown. Signed-off-by:
Henry Lin <henryl@nvidia.com> Signed-off-by:
Haotien Hsu <haotienh@nvidia.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20230727074927.2428611-1-haotienh@nvidia.comSigned-off-by:
-
- 26 Jul, 2023 12 commits
-
-
Takashi Iwai authored
This patch allows users to set up MIDI 1.0 ports more flexibly. Namely, instead of the fixed mapping only from FB 0, now multiple block definitions are applied to build up the MIDI 1.0 mapping. The each block config has midi1_first_group and midi1_num_groups attributes, and those specify which Groups are used for MIDI 1.0. Those fields must be within the UMP Groups defined in the block itself. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230725062206.9674-8-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Add a new ALSA control element to watch the current operation mode (MIDI 1.0 or MIDI 2.0). It's a read-only control that reflects the current value of altsetting, and 0 means unused, 1 for MIDI 1.0 (altset 0) and 2 for MIDI 2.0 (altset 1). Signed-off-by:
-
Takashi Iwai authored
Describing brief testing of the new MIDI 2.0 function driver. Signed-off-by:
-
Takashi Iwai authored
This patch extends MIDI 2.0 function driver to add more proper support for MIDI 1.0 interface. Before this patch, the driver only exposes the USB descriptor of a MIDI 1.0 interface in altset 0 while no actual I/O is running for it. This patch enables the actual I/O for the altset 0; the backend UMP rawmidi is translated from/to the MIDI 1.0 USB commands. For converting to USB MIDI 1.0 data protocol, a helper function is copied from the existing f_midi driver, in addition to a few other UMP Core helper functions. For the MIDI 1.0 OUT (that is, input for gadget), the incoming USB MIDI 1.0 packet is translated to UMP packets via UMP Core helper, and tossed to the attached UMP rawmidi. It's a relatively straightforward. OTOH, for MIDI 1.0 IN (i.e. output for gadget), it's a bit more complex: we need to convert a source UMP packet once to the standard MIDI 1.0 byte stream, and convert it again to USB MIDI 1.0 packets, then send them out. Signed-off-by:
-
Takashi Iwai authored
This patch extends MIDI 2.0 function driver to deal with more MIDI1 Jacks depending on the given Block configuration. For MIDI 1.0, we take the configuration given in Function Block 0, and create MIDI Jacks and Endpoints depending on the definition there. That is, when more UMP Groups are defined in the Block 0, the corresponding MIDI1 Jacks will be created. Signed-off-by:
-
Takashi Iwai authored
This patch adds the support of configfs to MIDI 2.0 function driver for users to allow configuring the UMP Endpoint and Function Blocks more flexibly. The configuration is in a tree form. The top-most contains some card-level configurations. UMP Endpoints are defined in subdirectories (ep.0, ep.1, etc) that contain Endpoint-specific configurations such as ep_name, etc. And, UMP Function Blocks are defined in the subdirectories (block.0, block.1, etc) under EP subdirectory. As default, the driver creates a single UMP Endpoint (ep.0) and a single Function Block (block.0) to work in a minimalistic manner. User can modify those attributes freely to fit with the demands. When multiple Function Blocks are required, user can create another directory as block.1, block.2, and so on (up to block.31). A block.* directory can be deleted dynamically, too. A caveat is that the block number has to be continuous. Similarly, when multiple UMP Endpoints are required, user can create another directory as ep.1, ep.2, up to ep.3. Also, some driver behavior can be controlled in the card top-level configs. e.g. you can pass process_ump=0 to disable the processing of UMP Stream messages. This would be equivalent with the older MIDI 2.0 spec that doesn't support UMP v1.1 features. The configfs interface checks upper- / lower-bound of input values, and more sanity checks are performed at binding. Attributes can't be changed any longer once when the instance is linked to UDC. Signed-off-by:
-
Takashi Iwai authored
This patch adds the support for USB MIDI 2.0 gadget function driver. The driver emulates a USB MIDI 2.0 interface with one or more UMP Endpoints, where each of UMP Endpoint is a pair of MIDI Endpoints for handling MIDI 2.0 UMP packets. When the function driver is bound, the driver creates an ALSA card object with UMP rawmidi devices. This is a kind of loop-back where the incoming and upcoming UMP packets from/to the MIDI 2.0 UMP Endpoints are transferred as-is. In addition, legacy (MIDI 1.0) rawmidi devices are created, so that legacy applications can work in the gadget side, too. When a USB MIDI 2.0 gadget interface appears, the connected host can use it with the snd-usb-audio driver where MIDI 2.0 support is enabled. Both gadget and connected hosts will have the similar UMP Endpoint and Function Block (or Group Terminal Block) information. Slight differences are the direction and UI-hint bits; it's due to the nature of gadget driver, and the input/output direction is swapped in both sides (the input for gadget is the output for host, and vice versa). The driver supports the brand-new UMP v1.1 feature, including the UMP Stream message handling for providing UMP Endpoint and Function Block information as well as dealing with the MIDI protocol switch. The driver responds to UMP Stream messages by itself. OTOH, MIDI-CI message handling isn't implemented in the kernel driver; it should be processed in the user-space through the loopback UMP device. As of this patch, the whole configuration is fixed, providing only one bidirectional UMP Endpoint containing a single FB/GTB with a single UMP Group. The configuration will be dynamically changeable in the following patches. The traditional MIDI 1.0 is still provided in the altset 0 (which is mandatory per spec). But it's only about the configuration, and no actual I/O will be running for the altset 0 as of this patch. The proper support MIDI 1.0 altset will follow in later patches, too. Signed-off-by:
-
Stanley Chang authored
Document the USB PHY bindings for Realtek SoCs. Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB controller and using USB 3.0 PHY transceiver. Signed-off-by:
Stanley Chang <stanley_chang@realtek.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230725033318.8361-5-stanley_chang@realtek.comSigned-off-by:
-
Stanley Chang authored
Document the USB PHY bindings for Realtek SoCs. Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB controller and using USB 2.0 PHY transceiver. Signed-off-by:
-
Stanley Chang authored
Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB controller. Added the driver to drive the USB 3.0 PHY transceivers. Signed-off-by:
-
Stanley Chang authored
Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB controller. Added the driver to drive the USB 2.0 PHY transceivers. Signed-off-by:
-
Stanley Chang authored
In Realtek SoC, the parameter of usb phy is designed to can dynamic tuning base on port status. Therefore, add a notify callback of phy driver when usb port status change. The Realtek phy driver is designed to dynamically adjust disconnection level and calibrate phy parameters. When the device connected bit changes and when the disconnected bit changes, do port status change notification: Check if portstatus is USB_PORT_STAT_CONNECTION and portchange is USB_PORT_STAT_C_CONNECTION. 1. The device is connected, the driver lowers the disconnection level and calibrates the phy parameters. 2. The device disconnects, the driver increases the disconnect level and calibrates the phy parameters. When controller to notify connect that device is already ready. If we adjust the disconnection level in notify_connect, the disconnect may have been triggered at this stage. So we need to change that as early as possible. The status change of connection is before port reset. Therefore, we add an api to notify phy the port status changes. In this stage, the device is not port enable, and it will not trigger disconnection. Signed-off-by:
-
- 25 Jul, 2023 14 commits
-
-
Ladislav Michl authored
Rename dwc3_data to dwc3_am62 to make it consistent with other glue drivers, it's clearer that this is am62's specific. While there, do the same for data variable. Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Link: https://lore.kernel.org/r/ZLKoHhJvT+Y6aM+C@lenochSigned-off-by:
-
Xu Yang authored
For mxs PHY, if there is a vbus but the bus is not enumerated, we need to force the dp/dm as SE0 from the controller side. If not, there is possible USB wakeup due to unstable dp/dm, since there is possible no pull on dp/dm, such as there is a USB charger on the port. Signed-off-by:
Xu Yang <xu.yang_2@nxp.com> Acked-by:
Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20230627110353.1879477-3-xu.yang_2@nxp.comSigned-off-by:
-
Xu Yang authored
The function mxs_phy_is_otg_host() will return true if OTG_ID_VALUE is 0 at USBPHY_CTRL register. However, OTG_ID_VALUE will not reflect the real state if the ID pin is float, such as Host-only or Type-C cases. The value of OTG_ID_VALUE is always 1 which means device mode. This patch will fix the issue by judging the current mode based on last_event. The controller will update last_event in time. Fixes: 7b09e676 ("usb: phy: mxs: refine mxs_phy_disconnect_line") Signed-off-by:
-
Xu Yang authored
Add USB PHY event for below situation: - usb role changed - vbus connect - vbus disconnect - gadget driver is enumerated USB PHY driver can get the last event after above situation occurs and deal with different situations. Signed-off-by:
-
Oliver Neukum authored
Documenting this ioctl along with the other ioctls Signed-off-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20230724092843.18410-1-oneukum@suse.comSigned-off-by:
-
Krzysztof Kozlowski authored
SDM660 SoC has two instances of DWC3 USB controller: one supporting USB 3.0 and one supporting only up to USB 2.0. The latter one does not use iface clock, so allow such variant to fix dtbs_check warnings: sda660-inforce-ifc6560.dtb: usb@c2f8800: clocks: [[37, 48], [37, 88], [37, 89], [37, 90]] is too short sda660-inforce-ifc6560.dtb: usb@c2f8800: clock-names:2: 'iface' was expected Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Krzysztof Kozlowski authored
The binding does not have to specify assigned-clocks, because they are already allowed by core DT schema. On the other hand, fixed assigned-clocks in the binding will not fit different boards or SoCs. Exactly this is the case for Qualcomm SuperSpeed DWC3 USB SoC controller binding, where few boards have different assigned-clocks: ipq8074-hk10-c1.dtb: usb@8cf8800: assigned-clocks: [[5, 131], [5, 132], [5, 133]] is too long sdm660-xiaomi-lavender.dtb: usb@a8f8800: assigned-clocks: [[37, 92], [37, 91], [38, 64]] is too long Signed-off-by:
-
Minda Chen authored
cdns3 just set PHY mode switch for USB3.0 PHY. If USB 2.0 PHY contains PHY mode switch setting, USB 2.0 PHY mode function can't be called. So add PHY mode switch function for USB 2.0 PHY. Signed-off-by:
Minda Chen <minda.chen@starfivetech.com> Reviewed-by:
Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230721095923.20445-1-minda.chen@starfivetech.comSigned-off-by:
-
Xu Yang authored
In some cases, the user may need to tune the rise/fall time of the high-speed transmitter waveform for USB Certification. This will add a parameter for this purpose. The value will be fetched from dtb and finally written to the register. Signed-off-by:
-
Xu Yang authored
The fsl,picophy-rise-fall-time-adjust property can help to adjust the rise/fall times of the high-speed transmitter waveform. The value can be 0~3. It has no unit. According to the description of USBNC_n_PHY_CFG1 register, the rise/fall time will be increased or decreased by a certain percentage relative to design default time if a value is given to this property. Signed-off-by:
-
Xu Yang authored
In current driver, the value of tuning parameter will not take effect if samsung,picophy-* is assigned as 0. Because 0 is also a valid value acccording to the description of USB_PHY_CFG1 register, this will improve the logic to let it work. Fixes: 58a3cefb ("usb: chipidea: imx: add two samsung picophy parameters tuning implementation") cc: <stable@vger.kernel.org> Signed-off-by:
-
Utkarsh Patel authored
Cable type such as active and retimer received as a part of Thunderbolt3 or Thunderbolt4 cable discover mode VDO needs to be configured in the thunderbolt alternate mode. Configuring the register bits for this cable type is changed with Intel Meteor Lake platform. BIT2 for Retimer/Redriver cable and BIT22 for Active/Passive cable. Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Utkarsh Patel <utkarsh.h.patel@intel.com> Link: https://lore.kernel.org/r/20230718024703.1013367-3-utkarsh.h.patel@intel.comSigned-off-by:
-
Varadarajan Narayanan authored
Document the IPQ5332 dwc3 compatible. Reviewed-by:
Varadarajan Narayanan <quic_varada@quicinc.com> Link: https://lore.kernel.org/r/cb89ff518890117b82d41d29d058de6662753bc8.1689913334.git.quic_varada@quicinc.comSigned-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by:
Herve Codina <herve.codina@bootlin.com> Signed-off-by:
-
