When these are not referenced, gcc prints a harmless warning:
drivers/phy/tegra/xusb.c:1286:12: error: 'tegra_xusb_padctl_resume_noirq' defined but not used [-Werror=unused-function]
1286 | static int tegra_xusb_padctl_resume_noirq(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/tegra/xusb.c:1276:12: error: 'tegra_xusb_padctl_suspend_noirq' defined but not used [-Werror=unused-function]
1276 | static int tegra_xusb_padctl_suspend_noirq(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: c545a90567 ("phy: tegra: xusb: Add sleepwalk and suspend/resume")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210721152550.2976003-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
To support XUSB host controller ELPG, this commit moves VBUS control
.phy_power_on()/.phy_power_off() to .phy_init()/.phy_exit().
When XUSB host controller enters ELPG, host driver invokes
.phy_power_off(), VBUS should remain ON so that USB devices will not
disconnect. VBUS can be turned OFF when host driver invokes
.phy_exit() which indicates disabling a USB port.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This commit implements Tegra210 XUSB PADCTL wake and sleepwalk
routines. Sleepwalk logic is in PMC (always-on) hardware block.
PMC driver provides managed access to the sleepwalk registers
via regmap framework.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This commit adds sleepwalk/wake and suspend/resume interfaces
to Tegra XUSB PHY driver.
Tegra XUSB host controller driver makes use of sleepwalk functions
to enable/disable sleepwalk circuit which is in always-on partition
and can respond to USB resume signals when controller is not powered.
Sleepwalk can be enabled/disabled for any USB UPHY individually.
- tegra_xusb_padctl_enable_phy_sleepwalk()
- tegra_xusb_padctl_disable_phy_sleepwalk()
Tegra XUSB host controller driver makes use of wake functions to
enable/disable/query wake circuit which is in always-on partition
can wake system up when USB resume happens.
Wake circuit can be enabled/disabled for any USB PHY individually.
- tegra_xusb_padctl_enable_phy_wake()
- tegra_xusb_padctl_disable_phy_wake()
- tegra_xusb_padctl_remote_wake_detected()
This commit also adds two system suspend stubs that can be used to
save and restore XUSB PADCTL context during system suspend and
resume.
- tegra_xusb_padctl_suspend_noirq()
- tegra_xusb_padctl_resume_noirq()
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
As per Tegra210 TRM, before changing lane assignments, driver should
keep lanes in IDDQ and sleep state; after changing lane assignments,
driver should bring lanes out of IDDQ.
This commit implements the required operations.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This commit is a preparation for enabling XUSB SC7 support.
It rearranges Tegra210 XUSB PADCTL UPHY initialization sequence,
for the following reasons:
1. PLLE hardware power sequencer has to be enabled only after both
PEX UPHY PLL and SATA UPHY PLL are initialized.
tegra210_uphy_init() -> tegra210_pex_uphy_enable()
-> tegra210_sata_uphy_enable()
-> tegra210_plle_hw_sequence_start()
-> tegra210_aux_mux_lp0_clamp_disable()
2. At cold boot and SC7 exit, the following bits must be cleared after
PEX/SATA lanes are out of IDDQ (IDDQ_DISABLE=1).
a. XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_CLAMP_EN,
b. XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_CLAMP_EN_EARLY
c. XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_VCORE_DOWN
tegra210_pex_uphy_enable() and tegra210_sata_uphy_enable() are in
charge of bringing lanes out of IDDQ, and then AUX_MUX_LP0_* bits
will be cleared by tegra210_aux_mux_lp0_clamp_disable().
3. Once UPHY PLL hardware power sequencer is enabled, do not assert
reset to PEX/SATA PLLs, otherwise UPHY PLL operation will be broken.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The programming sequence in tegra210_usb3_port_enable() is required
for both cold boot and SC7 exit, and must be performed only after
PEX/SATA UPHY is initialized. Therefore, this commit moves the
programming sequence to tegra210_usb3_phy_power_on(). PCIE/SATA phy
.power_on() stub will invoke tegra210_usb3_phy_power_on() if the lane
is assigned for XUSB super-speed.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Vinod writes:
phy-for-5.11
- New phy drivers:
- Mediatek MT7621 PCIe PHY (promoted from staging)
- Ingenic USB phy driver supporting JZ4775 and X2000
- Intel Keem Bay USB PHY driver
- Marvell USB HSIC PHY driver supporting MMP3 SoC
- AXG MIPI D-PHY driver
- Updates:
- Conversion to YAML binding for:
- Broadcom SATA PHY
- Cadence Sierra PHY bindings
- STM32 USBC Phy
- Support for Exynos5433 PCIe PHY
- Support for Qualcomm SM8250 PCIe QMP PHY
- Support for Exynos5420 USB2 phy
- devm_platform_ioremap_resource conversion for bunch of drivers
* tag 'phy-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (72 commits)
drm/mediatek: avoid dereferencing a null hdmi_phy on an error message
phy: ingenic: depend on HAS_IOMEM
phy: mediatek: statify mtk_hdmi_phy_driver
dt-bindings: phy: Convert Broadcom SATA PHY to YAML
devicetree: phy: rockchip-emmc add output-tapdelay-select
phy: rockchip-emmc: output tap delay dt property
PHY: Ingenic: Add USB PHY driver using generic PHY framework.
dt-bindings: USB: Add bindings for Ingenic JZ4775 and X2000.
USB: PHY: JZ4770: Remove unnecessary function calls.
devicetree: phy: rockchip-emmc: pulldown property
phy: rockchip: set pulldown for strobe line in dts
phy: renesas: rcar-gen3-usb2: disable runtime pm in case of failure
phy: mediatek: allow compile-testing the hdmi phy
phy/rockchip: Make PHY_ROCKCHIP_INNO_HDMI depend on HAS_IOMEM to fix build error
phy: samsung: Merge Kconfig for Exynos5420 and Exynos5250
phy: ralink: phy-mt7621-pci: set correct name in MODULE_DEVICE_TABLE macro
phy: ralink: phy-mt7621-pci: drop 'COMPILE_TEST' from Kconfig
phy: mediatek: Make PHY_MTK_{XSPHY, TPHY} depend on HAS_IOMEM and OF_ADDRESS to fix build errors
phy: tegra: xusb: Fix usb_phy device driver field
phy: amlogic: replace devm_reset_control_array_get()
...
The usb_get_maximum_speed() function is part of the usb-common module,
so enable it by selecting the corresponding Kconfig symbol.
While at it, also make sure to depend on USB_SUPPORT because USB_PHY
requires that. This can lead to Kconfig conflicts if USB_SUPPORT is not
enabled while attempting to enable PHY_TEGRA_XUSB.
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200330101038.2422389-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I have hit the following build error:
armv7a-hardfloat-linux-gnueabi-ld: drivers/phy/tegra/xusb.o: in function `tegra_xusb_port_unregister':
xusb.c:(.text+0x2ac): undefined reference to `usb_remove_phy'
armv7a-hardfloat-linux-gnueabi-ld: drivers/phy/tegra/xusb.o: in function `tegra_xusb_setup_ports':
xusb.c:(.text+0xf30): undefined reference to `usb_add_phy_dev'
PHY_TEGRA_XUSB should select USB_PHY because it uses symbols defined in
the code enabled by that.
Fixes: 23babe30fb45d ("phy: tegra: xusb: Add usb-phy support")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The device-managed allocation API doesn't work well with the life-cycle
of device objects. Since ports have device objects allocated within, it
can lead to situations where these devices need to stay around until
after their parent pad controller has been unbound from its driver. The
device-managed memory allocated for the port objects will, however, get
freed when the pad controller unbinds from the driver. This can cause
use-after-free errors down the road.
Note that the device is deleted as part of the driver unbind operation,
so there isn't much that can be done with it after that point, but the
memory still needs to stay around to ensure none of the references are
invalidated.
One situation where this arises is when a VBUS supply is associated with
a USB 2 or 3 port. When that supply is released using regulator_put() an
SRCU call will queue the release of the device link connecting the port
and the regulator after a grace period. This means that the regulator is
going to keep on to the last reference of the port device even after the
pad controller driver was unbound (which is when the memory backing the
port device is freed).
Fix this by allocating port objects using non-device-managed memory. Add
release callbacks for these objects so that their memory gets freed when
the last reference goes away. This decouples the port devices' lifetime
from the "active" lifetime of the pad controller (i.e. the time during
which the pad controller driver owns the device).
Signed-off-by: Thierry Reding <treding@nvidia.com>
Devices are created for each port of the XUSB pad controller. Each USB 2
and USB 3 port can potentially have an associated VBUS power supply that
needs to be removed when the device is removed.
Since port devices never bind to a driver, the driver core will not get
to perform the cleanup of device-managed resources that usually happens
on driver unbind.
Now, the driver core will also perform device-managed resource cleanup
for driver-less devices when they are released. However, when a device
link is created between the regulator and the port device, as part of
regulator_get(), the regulator takes a reference to the port device and
prevents it from being released unless regulator_put() is called, which
will never happen.
Avoid this by using the non-device-managed API and manually releasing
the regulator reference when the port is unregistered.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Probe deferral is an expected error condition that will usually be
recovered from. Print such error messages at debug level to make them
available for diagnostic purposes when building with debugging enabled
and hide them otherwise to not spam the kernel log with them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Deferred probe is an expected return value for tegra_fuse_readl().
Given that the driver deals with it properly, there's no need to
output a warning that may potentially confuse users.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for the XUSB pad controller found on Tegra194 SoCs. It is
mostly similar to the same IP found on Tegra186, but the number of
pads exposed differs, as do the programming sequences. Because most of
the Tegra194 XUSB PADCTL registers definition and programming sequence
are the same as Tegra186, Tegra194 XUSB PADCTL can share the same
driver, xusb-tegra186.c, with Tegra186 XUSB PADCTL.
Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it
is possible for some platforms have long signal trace that could not
provide sufficient electrical environment for Gen 2 speed. This patch
adds a "maximum-speed" property to usb3 ports which can be used to
specify the maximum supported speed for any particular USB 3.1 port.
For a port that is not capable of SuperSpeedPlus, "maximum-speed"
property should carry "super-speed".
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
As xusb-tegra186.c will be reused for Tegra194, it would be good to
protect Tegra186 soc data with CONFIG_ARCH_TEGRA_186_SOC. This commit
also reshuffles Tegra186 soc data single CONFIG_ARCH_TEGRA_186_SOC
will be sufficient.
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for set_mode on UTMI phy. This allow XUSB host/device mode
drivers to configure the hardware to corresponding modes.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for set_mode on USB 2 phy. This allow XUSB host/device mode
drivers to configure the hardware to corresponding modes.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
