Lt9611UXD Device Driver Base#645
Open
mohitdsor wants to merge 176 commits into
Open
Conversation
… compatible Define a Glymur compatible string for the QMP combo PHY, along with resource requirements. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-1-42133596bda0@oss.qualcomm.com/
Add the Glymur compatible to the M31 eUSB2 PHY, and use the SM8750 as the fallback. Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-3-42133596bda0@oss.qualcomm.com/
Add support for the GL3590 4 ports USB3.2 hub. This allows to control its reset pins with a gpio. Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
Add the binding for the USB3.2 Genesys Logic GL3590 hub. Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
…h hardware The Qualcomm Embedded USB Debugger (EUD) can intercept one or two independent High-Speed UTMI paths, depending on the SoC. Each path is distinct with its own HS-PHY interface, connector/controller wiring, and UTMI routing behavior. The EUD hardware sits between the USB2 PHY and the USB controller on each path. The existing binding models only a single UTMI path and does not provide a way to associate the required High-Speed USB PHY. EUD relies on the HS-PHY on the selected UTMI path for link signalling and correct operation of the hardware. Historically, EUD has worked on platforms that use a single UTMI path because the USB controller maintains ownership of the PHY during enumeration and normal operation. This implicit relationship allowed EUD to function even though the dependency on the PHY was not described in the binding. However, this behavior is not guaranteed by hardware. The current binding description is not sufficient for SoCs that expose two independent UTMI paths, where the PHY association and port wiring must be explicitly described. Introduce per-path eud-path child nodes so each UTMI path can describe its HS-PHY, port connections, and the role‑switching capability of its associated USB port. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-2-elson.serrao@oss.qualcomm.com/
EUD can be mapped to either the primary USB port or the secondary USB port depending on the value of the EUD_PORT_SEL register. Add a 'port' sysfs attribute to allow userspace to select which port EUD should operate on and update the ABI documentation. This is needed for systems with dual USB ports where EUD needs to be accessible on either port depending on the system configuration and use case. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-3-elson.serrao@oss.qualcomm.com/
EUD hardware can support multiple High-Speed USB paths, each routed through its own PHY. The active path is selected in hardware via the EUD_PORT_SEL register. As a High-Speed hub, EUD requires access to the High-Speed PHY associated with the active UTMI path. To support this multi-path capability, the driver must manage PHY resources on a per-path basis, ensuring that the PHY for the currently selected path is properly initialized and powered. This patch restructures the driver to implement per-path PHY management. The driver now powers the appropriate PHY based on the selected and enabled UTMI path, ensuring correct operation when EUD is enabled. Supporting this requires describing the available UTMI paths and their corresponding PHYs in Device Tree. This updates DT requirements and is not backward compatible with older DTs that lacked this description. Historically, EUD appeared to work on single-path systems because the USB controller kept the PHY initialized. However, EUD is designed to operate independently of the USB controller and therefore requires explicit PHY control. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-4-elson.serrao@oss.qualcomm.com/
The EUD hardware can support multiple High-Speed USB paths, each connected to different USB controllers. The current implementation uses a single chip-level role switch, which cannot properly handle multi-path configurations where each path needs independent role management. Since EUD is physically present between the USB connector and the controller, it should also relay the role change requests from the connector. Restructure the driver to support per-path role switches and remove the chip-level role switch. Additionally, as EUD need not modify the USB role upon enabling, remove the unnecessary role switch call from enable_eud(). Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-5-elson.serrao@oss.qualcomm.com/
Currently enable_store() allows operations irrespective of the EUD state, which can result in redundant operations. Avoid this by adding duplicate state checks to skip requests when EUD is already in the desired state. Additionally, improve error handling with explicit logging to provide better feedback. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-6-elson.serrao@oss.qualcomm.com/
EUD functions by presenting itself as a USB device to the host PC for debugging, making it incompatible in USB host mode configurations. Enabling EUD, when in host mode can also cause the USB controller to misbehave as the EUD hub can only have one upstream facing port. Handle below two scenarios to prevent these conflicts: 1. Prevent user from enabling EUD via sysfs when the USB port is in host mode. 2. Automatically disable EUD when USB port switches to host mode and re-enable it when exiting host mode. This ensures consistent state management without creating conflicts between the EUD debug hub and the USB controller. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-7-elson.serrao@oss.qualcomm.com/
EUD provides virtual USB attach/detach events to simulate cable plug/unplug while maintaining the physical debug connection. However, the current implementation incorrectly sets the USB role to HOST on virtual detach, which doesn't represent the disconnected state. Fix the virtual detach handling by setting the USB role to NONE instead of HOST, correctly representing the disconnected state. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> https://lore.kernel.org/linux-usb/20260126233830.2193816-8-elson.serrao@oss.qualcomm.com/
The EUD node does not match the current binding and maps USB endpoints to the secondary controller. This SoC supports EUD only on the primary High-Speed USB path. The binding also requires a per-path PHY reference. Model the primary UTMI path as a child node with the required PHY and an empty ports graph. Leave endpoint mapping to board DTS files, and remove the secondary mapping and associated ports so the description conforms to the binding. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> iLink: https://lore.kernel.org/linux-usb/20260126233830.2193816-9-elson.serrao@oss.qualcomm.com/
…nality On this board, EUD resides on the primary High-Speed USB data path between the connector and the DWC3 controller. Update the device tree connections to correctly map the connector and controller endpoints, and describe role-switch capability on the EUD primary path. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Link: https://lore.kernel.org/linux-usb/20260126233830.2193816-10-elson.serrao@oss.qualcomm.com/
For systems where the ID pin isn't available as gpio use the ATTACHED_STATE register instead to control vbus. >From the datasheet: "This is an additional method to communicate attach other than the ID pin. These bits can be read by the application to determine what was attached." Use this method if id-gpios property is not set, but the connector node has vbus-supply defined. Check regulator state as peripheral and detach can disable vbus. Signed-off-by: Jan Remmet <j.remmet@phytec.de>
The HD3SS3220's interrupt is disabled during system suspend, so a USB‑C cable connect/attach event cannot wake the system. This prevents resume from low‑power modes when the port controller is expected to act as a wakeup source. Add wakeup support by: - Initialize the device as wakeup‑capable. - Enable the HD3SS3220 IRQ as a wakeup interrupt. - Add suspend/resume callbacks to enable or disable the IRQ for wakeup depending on the device's wakeup configuration. With this, USB‑C cable insertion correctly wakes the system from suspend. Link: https://lore.kernel.org/all/20260215183325.3836178-2-swati.agarwal@oss.qualcomm.com/ Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
… functionality" This reverts commit e65028c. Issue is observed with this commit e65028c leading to crash, with following call stack [ 19.706310][ T73] Call trace: [ 19.706312][ T73] usb_role_switch_unregister+0x28/0x70 (P) [ 19.706319][ T73] eud_role_switch_release+0x30/0x78 [qcom_eud] [ 19.884972][ T73] devm_action_release+0x1c/0x30 [ 19.884981][ T73] release_nodes+0x70/0x120 [ 19.884987][ T73] devres_release_all+0x98/0xf0 [ 19.884995][ T73] device_unbind_cleanup+0x20/0x98 [ 19.885000][ T73] really_probe+0x184/0x3f0 [ 19.885005][ T73] __driver_probe_device+0x88/0x190 [ 19.885010][ T73] driver_probe_device+0x44/0x120 [ 19.885015][ T73] __device_attach_driver+0xc4/0x178 [ 19.885020][ T73] bus_for_each_drv+0x90/0xf8 [ 19.885027][ T73] __device_attach+0xa8/0x1d8 [ 19.885032][ T73] device_initial_probe+0x58/0x68 [ 19.885037][ T73] bus_probe_device+0x40/0xb8 [ 19.885041][ T73] deferred_probe_work_func+0xbc/0x128 [ 19.885046][ T73] process_one_work+0x180/0x450 [ 19.885055][ T73] worker_thread+0x26c/0x388 [ 19.885062][ T73] kthread+0x120/0x140 [ 19.885068][ T73] ret_from_fork+0x10/0x20 [ 19.885079][ T73] Code: f9000bf3 aa0003f3 b140041f 54000168 (390c901f) [ 19.885083][ T73] ---[ end trace 0000000000000000 ]--- [ 19.885088][ T73] Kernel panic - not syncing: Oops: Fatal exception [ 19.885091][ T73] SMP: stopping secondary CPUs Revert commit for now. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
This reverts commit 09ed0b6. Issue is observed with this commit 09ed0b6 leading to crash, with following call stack [ 19.706310][ T73] Call trace: [ 19.706312][ T73] usb_role_switch_unregister+0x28/0x70 (P) [ 19.706319][ T73] eud_role_switch_release+0x30/0x78 [qcom_eud] [ 19.884972][ T73] devm_action_release+0x1c/0x30 [ 19.884981][ T73] release_nodes+0x70/0x120 [ 19.884987][ T73] devres_release_all+0x98/0xf0 [ 19.884995][ T73] device_unbind_cleanup+0x20/0x98 [ 19.885000][ T73] really_probe+0x184/0x3f0 [ 19.885005][ T73] __driver_probe_device+0x88/0x190 [ 19.885010][ T73] driver_probe_device+0x44/0x120 [ 19.885015][ T73] __device_attach_driver+0xc4/0x178 [ 19.885020][ T73] bus_for_each_drv+0x90/0xf8 [ 19.885027][ T73] __device_attach+0xa8/0x1d8 [ 19.885032][ T73] device_initial_probe+0x58/0x68 [ 19.885037][ T73] bus_probe_device+0x40/0xb8 [ 19.885041][ T73] deferred_probe_work_func+0xbc/0x128 [ 19.885046][ T73] process_one_work+0x180/0x450 [ 19.885055][ T73] worker_thread+0x26c/0x388 [ 19.885062][ T73] kthread+0x120/0x140 [ 19.885068][ T73] ret_from_fork+0x10/0x20 [ 19.885079][ T73] Code: f9000bf3 aa0003f3 b140041f 54000168 (390c901f) [ 19.885083][ T73] ---[ end trace 0000000000000000 ]--- [ 19.885088][ T73] Kernel panic - not syncing: Oops: Fatal exception [ 19.885091][ T73] SMP: stopping secondary CPUs Revert commit for now. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…t handling" This reverts commit 7104631. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
This reverts commit 583d6fc. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
This reverts commit eb5da51. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
This reverts commit e7e656c. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
…ntrol" This reverts commit e2541a8. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
…election" This reverts commit c042ed7. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
…ulti-path hardware" This reverts commit cfe135b. Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
Add an optional consumer→provider phandle on USB connectors to reference the USB role-switch provider when no direct graph link exists. The DRD controller remains the provider via its 'usb-role-switch' property. Link: https://lore.kernel.org/all/20260223191042.825136-2-elson.serrao@oss.qualcomm.com/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
…iguration EUD hardware supports debugging on up to two USB ports depending on the SoC configuration. Debugging can be selected on either the primary or secondary USB port as controlled by the EUD_PORT_SELECT register. Extend the binding to support dual-port configurations by adding port@2 and port@3 for secondary USB controller and Type-C connector connections. Link: https://lore.kernel.org/all/20260309203337.803986-2-elson.serrao@oss.qualcomm.com/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
EUD can be mapped to either the primary USB port or the secondary USB port depending on the value of the EUD_PORT_SEL register. Add a 'port' sysfs attribute to allow userspace to select which port EUD should operate on and update the ABI documentation. This is needed for systems with dual USB ports where EUD needs to be accessible on either port depending on the system configuration and use case. Link: https://lore.kernel.org/all/20260309203337.803986-3-elson.serrao@oss.qualcomm.com/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
EUD hardware can support multiple High-Speed USB ports, each routed through its own PHY. The active port is selected in hardware via the EUD_PORT_SEL register. As a High-Speed hub, EUD requires access to the High-Speed PHY associated with the active port. To support this multi-port capability, the driver must manage PHY resources on a per-port basis, ensuring that the PHY for the currently selected port is properly initialized and powered. This patch adds per-port PHY management to the driver. The driver now powers the appropriate PHY based on the selected and enabled port, ensuring correct operation when EUD is enabled. Historically, EUD appeared to work on single-port systems because the USB controller kept the PHY initialized. However, EUD is designed to operate independently of the USB controller and therefore requires explicit PHY control for proper operation. Link: https://lore.kernel.org/all/20260309203337.803986-4-elson.serrao@oss.qualcomm.com/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
The EUD hardware can support multiple High-Speed USB ports, each connected to different USB controllers. The current implementation uses a single chip-level role switch, which cannot properly handle multi-port configurations where each USB port can operate in different role. Restructure the driver to support per-port role switches. Additionally, remove the unnecessary role switch call from enable_eud() as EUD need not modify the USB role upon enabling. Link: https://lore.kernel.org/all/20260309203337.803986-5-elson.serrao@oss.qualcomm.com/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
Currently enable_store() allows operations irrespective of the EUD state, which can result in redundant operations. Avoid this by adding duplicate state checks to skip requests when EUD is already in the desired state. Additionally, improve error handling with explicit logging to provide better feedback. Link: https://lore.kernel.org/all/20260309203337.803986-6-elson.serrao@oss.qualcomm.com/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/kaanapali.dtsi
# Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml # drivers/remoteproc/qcom_q6v5_pas.c # drivers/soc/qcom/smem.c
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…org/pub/scm/linux/kernel/git/torvalds/linux.git tech/bsp/clk eea3e98 11 tech/bsp/devfreq a0c2f21 6 tech/bsp/ec 643c24b 2 tech/bsp/soc-infra 20c09ce 3 tech/bsp/pinctrl 3f1acf8 1 tech/bsp/remoteproc a7b9b6d 10 tech/bus/peripherals 287f0f5 8 tech/bus/pci/all c266573 14 tech/bus/pci/phy aaf8ef1 4 tech/bus/usb/dwc 49ac8e0 2 tech/bus/usb/phy 8c7f91d 35 tech/debug/hwtracing 25c6a74 30 tech/pmic/misc ee32a8c 5 tech/mem/iommu 1fa98cb 5 tech/mm/audio/all cab3357 10 tech/mm/camss 147ae87 28 tech/mm/drm 2fbdd74 60 tech/mm/fastrpc e0ba718 9 tech/mm/phy 56ccbf4 1 tech/mm/video 8bbe314 36 tech/mm/gpu cee7794 5 tech/net/ath 850c3c0 15 tech/net/phy a3602e9 1 tech/net/bluetooth 9cca493 2 tech/pm/power 2d42c35 9 tech/pm/thermal 3f033cb 7 tech/security/crypto f030676 14 tech/security/ice 1564b82 25 tech/storage/phy cf1667f 1 tech/storage/all e254dae 1 tech/all/dt/qcs6490 58c1242 20 tech/all/dt/qcs9100 b51f0ee 18 tech/all/dt/qcs8300 ffd35fe 16 tech/all/dt/qcs615 9e2f111 9 tech/all/dt/agatti c828f10 1 tech/all/dt/hamoa 670d002 29 tech/all/dt/glymur 29aa2ab 25 tech/all/dt/kaanapali 33d3cd7 11 tech/all/dt/pakala fee7c34 8 tech/all/config ff67f6a 61 tech/overlay/dt bc66459 47 tech/all/workaround d15f5a1 15 tech/mproc/all 0aa90b7 3 tech/noup/debug/all d2b684d 25 tech/hwe/unoq b2ea57b 5 early/hwe/shikra/drivers b26f0d6 86 early/hwe/shikra/dt 919fd6c 61
The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware based power monitoring and limiting capabilities for various power domains including System, SoC, CPU clusters, GPU, and various other subsystems for glymur. Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-qcom_spel_driver_upstream-v1-3-75356d1b7f94@oss.qualcomm.com
… operation Add explicit data-lanes to the MDSS DP output endpoints to enable display port in 2 lanes configuration and disable the mode-switch property from the USB QMP PHY node. Signed-off-by: Saurabh Anand <saurabh.anand@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260521120058.2966709-1-saurabh.anand@oss.qualcomm.com/
The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware based power monitoring and limiting capabilities for various power domains including System, SoC, CPU clusters, GPU, and various other subsystems. The driver integrates with the Linux powercap framework, exposing SPEL capabilities through powercap sysfs interfaces. This allows userspace applications and thermal management daemons to monitor energy consumption and configure power limits for optimal power/performance balance. Signed-off-by: Aastha Pandey <aastha.pandey@oss.qualcomm.com>
mohitdsor
force-pushed
the
lt9611uxd-support
branch
from
63ab498 to
64510aa
Compare
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
1 similar comment
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
|
Merge Check Failed: No Change Task Found No associated change tasks found for CR 4552827 on any of the following entities: Entities:
CR: 4552827 Please ensure the CR has a change task associated with at least one of the entities for this branch. |
added 2 commits
June 3, 2026 01:57
LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Link : https://lore.kernel.org/lkml/20260508134009.4582-3-syyang@lontium.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Link : https://lore.kernel.org/lkml/20260508134009.4582-3-syyang@lontium.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
mohitdsor
force-pushed
the
lt9611uxd-support
branch
from
64510aa to
049d3ab
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Patches for LT9611UXD Device Driver
CRs-Fixed: 4552827