Lanes can use other lanes' reference clocks, as determined by refclk.
Use refclk to determine the clock to enable/disable instead of always
using the lane's own reference clock. This ensures the clock selected in
xpsgtr_configure_pll is the one enabled.
For the other half of the equation, always program REF_CLK_SEL even when
we are selecting the lane's own clock. This ensures that Linux's idea of
the reference clock matches the hardware. We use the "local" clock mux
for this instead of going through the ref clock network.
Fixes: 25d7008335 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save")
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240628205540.3098010-2-sean.anderson@linux.dev
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Compile testing configurations without REGMAP support enabled results in
a bunch of errors being reported:
../drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:569:21: error: variable ‘rk_hdptx_phy_regmap_config’ has initializer but incomplete type
569 | static const struct regmap_config rk_hdptx_phy_regmap_config = {
| ^~~~~~~~~~~~~
../drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:570:10: error: ‘const struct regmap_config’ has no member named ‘reg_bits’
570 | .reg_bits = 32,
| ^~~~~~~~
Note that selecting REGMAP alone is not enough, because of the following
liker error:
phy-rockchip-samsung-hdptx.c:(.text+0x10c): undefined reference to `__devm_regmap_init_mmio_clk'
Instead of the obvious fix to enable REGMAP_MMIO, select MFD_SYSCON,
which implicitly enables REGMAP_MMIO as well. The rationale is that the
driver has been already relying on the syscon functionality.
Moreover, without MFD_SYSCON enabled, the test coverage is reduced,
since the linker might not detect any potential undefined references
following syscon_regmap_lookup_by_phandle() invocation in
rk_hdptx_phy_probe() body. That is because the function would
unconditionally return -ENOTSUP, hence the compiler is free to optimize
out any unreachable code.
Finally ensure PHY_ROCKCHIP_SAMSUNG_HDPTX depends on HAS_IOMEM, as
required by MFD_SYSCON.
Fixes: 553be2830c ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240629-rk-hdptx-compile-test-fix-v1-1-c86675ba8070@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add i.MX8QM HSIO PHY driver support.
i.MX8QM HSIO has three lane PHY instances, and can be bound to the
following controllers in the different use cases listed in below table.
- two lanes capable PCIEA controller.
- one lane PCIEB controller.
- AHCI SATA controller.
i.MX8QM HSIO PHYs support the following use cases.
+----------------------------------------------------+
| | Lane0| Lane1| Lane2|
|-------------------------------|------|------|------|
| use case 1: PCIEAX2SATA | PCIEA| PCIEA| SATA |
|-------------------------------|------|------|------|
| use case 2: PCIEAX2PCIEB | PCIEA| PCIEA| PCIEB|
|-------------------------------|------|------|------|
| use case 3: PCIEAPCIEBSATA | PCIEA| PCIEB| SATA |
+----------------------------------------------------+
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/1716962565-2084-3-git-send-email-hongxing.zhu@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Existing device trees specify only a single clock-output-name for the
PCIe PHYs. The function phy_aux_clk_register() expects a second entry in
that property. When it doesn't find it, it returns an error, thus
failing the probe of the PHY and thus breaking support for the
corresponding PCIe host.
Follow the approach of the combo USB+DT PHY and generate the name for
the AUX clocks instead of requiring it in DT.
Fixes: 583ca9ccfa ("phy: qcom: qmp-pcie: register second optional PHY AUX clock")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240614-fix-pcie-phy-compat-v3-1-730d1811acf4@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
While commit 255ec3879d ("phy: exynos5-usbdrd: Add 26MHz ref clk
support") correctly states that CLKRSTCTRL[7:5] doesn't need to be set
on modern Exynos platforms, SSPPLLCTL[2:0] should be programmed with
the frequency of the reference clock for the USB2.0 phy instead.
I stumbled across this while adding support for the Google Tensor
gs101, but this should apply to E850 just the same.
Do so.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://lore.kernel.org/r/20240507-samsung-usb-phy-fixes-v1-5-4ccba5afa7cc@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Using 0x82 seems odd, where everything else is just a sequence.
On E850, this macro isn't used (as a register value), only to assign
its value to the 'extrefclk' variable, which is otherwise unused on
that platform. Older platforms don't appear to support 26MHz in the
first place (since this macro was added for E850).
Furthermore, the downstream driver uses 0x82 to denote
USBPHY_REFCLK_DIFF_26MHZ (whatever that means exactly), but for all the
other values we match downstream's non-DIFF macros.
Update to avoid confusion. No functional change intended.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://lore.kernel.org/r/20240507-samsung-usb-phy-fixes-v1-4-4ccba5afa7cc@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The timers-howto recommends using usleep_range() and friends anytime
waiting for >= ~10us is required. Doing so can help the timer subsystem
a lot to coalesce wakeups.
Additionally, fsleep() exists as a convenient wrapper so we do not have
to think about which exact sleeping function is required in which case.
Convert all udelay() calls in this driver to use fsleep() to follow the
recommendataion.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://lore.kernel.org/r/20240507-samsung-usb-phy-fixes-v1-2-4ccba5afa7cc@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Most of the macros are ordered high -> low, but there are some
outliers.
Order them all uniformly from high to low. This will allow adding
additional register (field) definitions in a consistent way.
While at it, also remove some extra empty lines to group register bit
field definitions together with the relevant register. This makes the
registers easier to distinguish visually.
No functional change.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://lore.kernel.org/r/20240507-samsung-usb-phy-fixes-v1-1-4ccba5afa7cc@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Runtime PM is not supported while USB PHY can be turned off from
register accesses.
Add runtime PM for the USB2.0 PHY. The PHY is entirely shut down to save
as much power as possible. This means that gadgets will not be discovered
once suspend state is entered, and suspend state can not be left without
an explicit user intervention (through sysfs). That's why runtime PM is
disabled by default.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240528102026.40136-2-bastien.curutchet@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, none of the X1E80100 supported boards upstream have enabled
DP. As for USB, the reason it is not broken when it's obvious that the
offsets are wrong is because the only difference with respect to USB is
the difference in register name. The V6 uses QPHY_V6_PCS_CDR_RESET_TIME
while V6 N4 uses QPHY_V6_N4_PCS_RX_CONFIG. Now, in order for the DP to
work, the DP serdes tables need to be added as they have different
values for V6 N4 when compared to V6 ones, even though they use the same
V6 offsets. While at it, switch swing and pre-emphasis tables to V6 as
well.
Fixes: d7b3579f84 ("phy: qcom-qmp-combo: Add x1e80100 USB/DP combo phys")
Co-developed-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240527-x1e80100-phy-qualcomm-combo-fix-dp-v1-3-be8a0b882117@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Even if a PHY is already configured, the PHY operations are needed during
resume stage, as the PHY is in reset state.
The noop_ops PHY operations is removed to always have PHY operations.
The already_configured flag is checked at the begening of init, configure
and poweron operations to keep the already_configured behaviour.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Link: https://lore.kernel.org/r/20240412-j7200-phy-s2r-v1-7-f15815833974@bootlin.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The wiz_clock_init() function mixes probe and hardware configuration.
Rename the wiz_clock_init() to wiz_clock_probe() and move the hardware
configuration part in a new function named wiz_clock_init().
This hardware configuration sequence must be called during the resume
stage of the driver.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Link: https://lore.kernel.org/r/20240412-j7200-phy-s2r-v1-2-f15815833974@bootlin.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Updates for v6.10
Core:
- Switched to generating register header files during build process
instead of shipping pre-generated headers
- Merged DPU and MDP4 format databases.
DP:
- Stop using compat string to distinguish DP and eDP cases
- Added support for X Elite platform (X1E80100)
- Reworked DP aux/audio support
- Added SM6350 DP to the bindings (no driver changes, using SM8350
as a fallback compat)
GPU:
- a7xx perfcntr reg fixes
- MAINTAINERS updates
- a750 devcoredump support
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGtpw6dNR9JBikFTQ=TCpt-9FeFW+SGjXWv+Jv3emm0Pbg@mail.gmail.com
The newly added driver causes a warning about missing dependencies
by selecting CONFIG_TYPEC unconditionally:
WARNING: unmet direct dependencies detected for TYPEC
Depends on [n]: USB_SUPPORT [=n]
Selected by [y]:
- PHY_ROCKCHIP_USBDP [=y] && ARCH_ROCKCHIP [=y] && OF [=y]
WARNING: unmet direct dependencies detected for USB_COMMON
Depends on [n]: USB_SUPPORT [=n]
Selected by [y]:
- EXTCON_RTK_TYPE_C [=y] && EXTCON [=y] && (ARCH_REALTEK [=y] || COMPILE_TEST [=y]) && TYPEC [=y]
Since that is a user-visible option, it should not really be selected
in the first place. Replace the 'select' with a 'depends on' as
we have for similar drivers.
Fixes: 2f70bbddeb ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240415174241.77982-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
>From the RK3588 Technical Reference Manual, Part1,
section 6.19 PCIe3PHY_GRF Register Description:
"rxX_cmn_refclk_mode"
RX common reference clock mode for lane X. This mode should be enabled
only when the far-end and near-end devices are running with a common
reference clock.
The hardware reset value for this field is 0x1 (enabled).
Note that this register field is only available on RK3588, not on RK3568.
The link training either fails or is highly unstable (link state will jump
continuously between L0 and recovery) when this mode is enabled while
using an endpoint running in Separate Reference Clock with No SSC (SRNS)
mode or Separate Reference Clock with SSC (SRIS) mode.
(Which is usually the case when using a real SoC as endpoint, e.g. the
RK3588 PCIe controller can run in both Root Complex and Endpoint mode.)
Add support for the device tree property rockchip,rx-common-refclk-mode,
such that the PCIe PHY can be used in configurations where the Root
Complex and Endpoint are not using a common reference clock.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240412125818.17052-3-cassel@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This adds a new USBDP combo PHY with Samsung IP block driver.
The driver get lane mux and mapping info in 2 ways, supporting
DisplayPort alternate mode or parsing from DT. When parsing from DT,
the property "rockchip,dp-lane-mux" provide the DP mux and mapping
info. This is needed when the PHY is not used with TypeC Alt-Mode.
For example if the USB3 interface of the PHY is connected to a USB
Type A connector and the DP interface is connected to a DisplayPort
connector.
When do DP link training, need to set lane number, link rate, swing,
and pre-emphasis via PHY configure interface.
Co-developed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Co-developed-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Co-developed-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20240408225109.128953-3-sebastian.reichel@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The power_supply frame-work is not really designed for there to be
long living in kernel references to power_supply devices.
Specifically unregistering a power_supply while some other code has
a reference to it triggers a WARN in power_supply_unregister():
WARN_ON(atomic_dec_return(&psy->use_cnt));
Folllowed by the power_supply still getting removed and the
backing data freed anyway, leaving the tusb1210 charger-detect code
with a dangling reference, resulting in a crash the next time
tusb1210_get_online() is called.
Fix this by only holding the reference in tusb1210_get_online()
freeing it at the end of the function. Note this still leaves
a theoretical race window, but it avoids the issue when manually
rmmod-ing the charger chip driver during development.
Fixes: 48969a5623 ("phy: ti: tusb1210: Add charger detection")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240406140821.18624-1-hdegoede@redhat.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add driver for MediaTek's XFI T-PHY which can be found in the MT7988
SoC. The XFI T-PHY is a 10 Gigabit/s Ethernet SerDes PHY with muxes on
the internal side to be used with either USXGMII PCS or LynxI PCS,
depending on the selected PHY interface mode.
The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
PHY_INTERFACE_MODE_* corresponding to the supported modes:
* USXGMII \
* 10GBase-R }- USXGMII PCS - XGDM \
* 5GBase-R / \
}- Ethernet MAC
* 2500Base-X \ /
* 1000Base-X }- LynxI PCS - GDM /
* Cisco SGMII (MAC side) /
I chose the name XFI T-PHY because names of functions dealing with the
phy in the vendor driver are prefixed "xfi_pextp_".
The register space used by the phy is called "pextp" in the vendor
sources, which could be read as "_P_CI _ex_press _T_-_P_hy", and that
is quite misleading as this phy isn't used for anything related to
PCIe, so I wanted to find a better name.
XFI is still somehow related (as in: you would find the relevant
places using grep in the vendor driver when looking for that) and the
term seemed to at least somehow be aligned with the function of that
phy: Dealing with (up to) 10 Gbit/s Ethernet serialized differential
signals.
In order to work-around a performance issue present on the first of
two XFI T-PHYs found in MT7988, special tuning is applied which can
be selected by adding the 'mediatek,usxgmii-performance-errata'
property to the device tree node, similar to how the vendor driver is
doing that too.
There is no documentation for most registers used for the
analog/tuning part, however, most of the registers have been partially
reverse-engineered from MediaTek's SDK implementation (see links, an
opaque sequence of 32-bit register writes) and descriptions for all
relevant digital registers and bits such as resets and muxes have been
supplied by MediaTek.
Link: b72d6cba92/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_sgmii.c
Link: dec96a1d9b/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_eth_soc.c
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/r/8719c82634df7e8e984f1a608be3ba2f2d494fb4.1712625857.git.daniel@makrotopia.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
