The Apple Type-C PHY (ATCPHY) is a PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort connectivity found in Apple Silicon SoCs.
The PHY handles muxing between these different protocols and also provides
the reset controller for the attached dwc3 USB controller.
There is no documentation available for this PHY and the entire sequence
of MMIO pokes has been figured out by tracing all MMIO access of Apple's
driver under a thin hypervisor and correlating the register reads/writes
to their kernel's debug output to find their names. Deviations from this
sequence generally results in the port not working or, especially when
the mode is switched to USB4 or Thunderbolt, to some watchdog resetting
the entire SoC.
This initial commit already introduces support for Display Port and
USB4/Thunderbolt but the drivers for these are not ready. We cannot
control the alternate mode negotiation and are stuck with whatever Apple's
firmware decides such that any DisplayPort or USB4/Thunderbolt device will
result in a correctly setup PHY but not be usable until the other drivers
are upstreamed as well.
Co-developed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Co-developed-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> # for reset controller
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://patch.msgid.link/20251214-b4-atcphy-v3-3-ba82b20e9459@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Set the regulator load before enabling the regulators to ensure stable
operation and proper power management on platforms where regulators are
shared between the QMP USB PHY and other IP blocks.
Introduce a regulator data structure with explicit enable load values and
use the regulator framework's `init_load_uA` field along with
`devm_regulator_bulk_get_const()` to ensure that `regulator_set_load()` is
applied automatically before the first enable, providing consistent power
management behavior across platforms.
Signed-off-by: Faisal Hassan <faisal.hassan@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20250905101243.14815-1-faisal.hassan@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Introduce a driver that supports three PHYs found on the SpacemiT
K1 SoC. The first PHY is a combo PHY that can be configured for
use for either USB 3 or PCIe. The other two PHYs support PCIe
only.
All three PHYs must be programmed with an 8 bit receiver termination
value, which must be determined dynamically. Only the combo PHY is
able to determine this value. The combo PHY performs a special
calibration step at probe time to discover this, and that value is
used to program each PHY that operates in PCIe mode. The combo
PHY must therefore be probed before either of the PCIe-only PHYs
will be used.
Each PHY has an internal PLL driven from an external oscillator.
This PLL started when the PHY is first initialized, and stays
on thereafter.
During normal operation, the USB or PCIe driver using the PHY must
ensure (other) clocks and resets are set up properly.
However PCIe mode clocks are enabled and resets are de-asserted
temporarily by this driver to perform the calibration step on the
combo PHY.
Tested-by: Junzhong Pan <panjunzhong@linux.spacemit.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/all/ba532f8d-a452-40e5-af46-b58b89f70a92@linaro.org/ [1]
Tested-by: Yixun Lan <dlan@gentoo.org>
Link: https://patch.msgid.link/20251218151235.454997-4-elder@riscstar.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Attempting to make use of a 1080p@120Hz display mode with 10 bpc RGB on
my Acer XV275K P3 monitor results in a blank image. A similar behavior
has been reported on Philips 279M1RV.
The faulty modeline is created by drm_gtf_mode_complex() based on the
following EDID entry from the Standard Timings block:
GTF: 1920x1080 119.999987 Hz 16:9 138.840 kHz 368.759000 MHz
It's worth noting the computed pixel clock ends up being slightly higher
at 368.881000 MHz. Nevertheless, this seems to work consistently fine
with 8 bpc RGB.
After switching to 10 bpc, the TMDS character rate expected for the mode
increases to 461.101250 MHz, as per drm_hdmi_compute_mode_clock().
Since there is no entry for this rate in the ropll_tmds_cfg table, the
necessary HDMI PLL configuration parameters are calculated dynamically
by rk_hdptx_phy_clk_pll_calc(). However, the resulting output rate is
not quite a perfect match, i.e. 461.100000 MHz. That proved to be the
actual root cause of the problem.
Add a new entry to the TMDS configuration table and provide the
necessary frequency division coefficients for the PHY PLL to generate
the expected 461.101250 MHz output.
Fixes: 9d0ec51d7c ("phy: rockchip: samsung-hdptx: Add high color depth management")
Tested-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20251221-phy-hdptx-pll-fix-v2-1-ae4abf7f75a1@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The PHY core defines phy_pm_runtime_put() to return an int, but that
return value is never used. It also passes the return value of
pm_runtime_put() to the caller which is not very useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
value and change its return type to void. Also drop the redundant
pm_runtime_enabled() call from there.
No intentional functional impact.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2556645.jE0xQCEvom@rafael.j.wysocki
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Passing pm_runtime_put() return value to the callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update samsung_mipi_dcphy_exit() to simply discard the
return value of pm_runtime_put() and always return success to the
caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2281919.Icojqenx9y@rafael.j.wysocki
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Printing error messages on pm_runtime_put() returning negative values
is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Accordingly, update mixel_lvds_phy_reset() to simply discard the return
value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2012926.taCxCBeP46@rafael.j.wysocki
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When making use of the clock provider functionality, the output clock
does normally match the TMDS character rate, which is what the PHY PLL
gets configured to.
However, this is only applicable for default color depth of 8 bpc. For
higher depths, the output clock is further divided by the hardware
according to the formula:
output_clock_rate = tmds_char_rate * 8 / bpc
Since the existence of the clock divider wasn't taken into account when
support for high bpc has been introduced, make the necessary adjustments
to report the correct clock rate.
Fixes: 9d0ec51d7c ("phy: rockchip: samsung-hdptx: Add high color depth management")
Reported-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251028-phy-hdptx-fixes-v1-1-ecc642a59d94@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The "phy_id" comes from the device tree so it's going to be correct.
But static checkers sometimes complain when we have an upper bounds
check with no lower bounds check. Also it's a bit unusual that the
lowest valid number is 1 instead of 0 so adding a check could
potentially help someone.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/aPJpB-QI8FMpFGOk@stanley.mountain
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The QMP USB3/DP Combo PHY hosts an USB3 phy and a DP PHY on top
of a combo glue to route either lanes to the 4 shared physical lanes.
The routing of the lanes can be:
- 2 DP + 2 USB3
- 4 DP
- 2 USB3
Get the lanes mapping from DT and stop registering the USB-C
muxes in favor of a static mode and orientation detemined
by the lanes mapping.
This allows supporting boards with direct connection of USB3 and
DisplayPort lanes to the QMP Combo PHY lanes, not using the
USB-C Altmode feature.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Xilin Wu <sophon@radxa.com> # qcs6490-radxa-dragon-q6a
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251119-topic-x1e80100-hdmi-v7-2-2bee0e66cc1b@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Biju <biju.das.au@gmail.com> says:
This patch series aims to add Renesas RZ/G3E USB3.0 PHY driver support.
This module is connected between USB3 Host and PHY module. The main
functions of this module are:
1) Reset control
2) Control of PHY input pins
3) Monitoring of PHY output pins
Biju Das (2):
dt-bindings: phy: renesas: Document Renesas RZ/G3E USB3.0 PHY
phy: renesas: Add Renesas RZ/G3E USB3.0 PHY driver
Link: https://patch.msgid.link/20251029084037.108610-1-biju.das.jz@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
